-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Read and apply SCRFs internally #67
Comments
+1 on this. |
Since the SCRF code we use for GMET (and used for the GMET version of GARD) is also in Fortran, how difficult would it be to connect it as a subroutine? |
Almost trivial I suspect, but it still depends on NR and I don’t want that dependency in GARD. Once that is ironed out I would prefer to have it as a subroutine.
… On Jun 8, 2018, at 8:59 PM, Andy Wood ***@***.***> wrote:
Since the SCRF code we use for GMET (and used for the GMET version of GARD) is also in Fortran, how difficult would it be to connect it as a subroutine?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Provide an option to GARD to read in pre-computed SCRF fields so they can be used with, e.g., sample_analog or simply used to apply the error and pop terms internally.
This could go along with only writing final output, instead of writing (and having to save) mean, error, and pop fields. This could save a lot of memory and enable longer runs without having to break it up.
The text was updated successfully, but these errors were encountered: