Compare GMET SCRF algorithm to others in the literature

[jhamman]

In today's group meeting, we discussed that it would be beneficial to explore other existing SCRF methods that have been developed since @martynpclark wrote the algorithm included in this repository.

@martynpclark @gutmann @anewman89

[jhamman]

from @andywood:
there are now a number of R & python codes for this, it seems -- eg, http://strimas.com/prioritizr/, https://cran.r-project.org/web/packages/RandomFields/RandomFields.pdf ... not sure if it's important to stay in the Fortran framework

---

I tend to agree here. If we can get something in Python, I would like to use some of my Pangeo time to work this into the GARD post processing and that could also benefit GMET.

[anewman89]

I had a conversation with Doug Nychka about porting GMET to R. He does all his high power statistics/spatial regression in R and thought it would be better to have our work in R. I wasn't sold, but if R is somewhat comparable in speed to Fortran that could also be an option.

[bartnijssen]

@anewman89 : What was the motivation? Speed, convenience or expandability? I think speed is only one consideration here. If it allows much easier expansion of methods then maybe it's worth it, but only if that is something you want to target.

[anewman89]

@bartnijssen Doug's motivation was convenience. He thought more people would be open to working with R than Fortran. I'm not suggesting we go to R, but it is interesting to think about. I'll have to give it more thought on what doors R would open for us as far as algorithmic developments.

[bartnijssen]

@anewman89 I think that is potentially a good reason for switching if there really is an audience that will pick this up and expand on it. The Fortran audience is small (same for C audience), whereas the R / python etc. audiences are much larger. And R still beats out python handily for a lot of stats work.

[jhamman]

I think we could go back and forth on if we should move from Fortran to R or Python forever. Before we do, let's ask a few questions:

1. What are are motivations for altering our current approach to generating spatially correlated random fields? That question should be discussed in Desired improvements to SCRFs #7.
2. What other tools are out there? And are the sufficient for our needs? That is the topic of this conversation.

So here I'll start the process of documenting our options on the subject:

Template
#### Name
  - Description: [1 liner]
  - Link(s): [papers and/or package docs]
  - Differences w/ GMET SCRF: [main differences with GMET's current approach]
  - Software available: [Yes/No, language, link if applicable]

---

Clark and Slater (2006) -- Hierarchical Generation of SCRFs

• Description: Current GMET implementation
• Link(s): https://doi.org/10.1175/JHM474.1
• Differences w/ GMET SCRF: None
• Software available: Yes, Fortran, https://github.com/NCAR/GMET (not currently distributable because it depends on Numerical Recipes)

[andywood]

I think in addition to what Bart mentioned, maintainability is an objective as well as portability (ease of implementation on different platforms), and flexibility (eg ability to handle different problems, possible very large domains). R codes/libraries tend to be pretty stable (though not as stable as fortran) but a big advantage to me is that they allow for concise code and easy/interactive debugging. They're transparent as well (ie you can open and modify library code -- it's just more R). R will be slower than the Fortran equivalent, and potentially use memory less efficiently as it's not configurable as in Fortran).