unable to create a scratch variable in existing scratch group or a package group #17
Comments
|
I'm not exactly sure what you mean with this. I'd have to see examples of the two cases you described as failing to know if they should have, or what the cause was. My guess is that at a minimum the second one is a feature (i.e. you can't add variables within a package, and package variables can't be defined as scratch), but I'd need more information to be sure. |
|
My expectation that was that I could create a scratch variable anywhere, and so the first thing I had tried was creating variables with persistence="scratch" inside of a package. This never compiled (I don't have the compilation logs anymore). I had put these inside the amOkuboWeiss variable definitions in Registry_okubo_weiss.xml My second attempt was to create scratch variables inside of a <var_struct name="scratch"> inside of Registry_okubo_weiss.xml (i.e., adding new scratch variables to the existing "scratch" container). This one failed at runtime, as there was a backtrace crash when I called mpas_allocate_scratch_field in mpas_grid_types.F. I fixed it by creating a new <var_struct name="okuboWeissScratch"> set, and defining my scratch variables inside of there. |
|
The only place you can define variables is within a I'd have to see the examples from the second case to know if it's a real issue or just incorrect usage. But I think I can say pretty certainly (if my understanding is correct) that the first is just incorrect usage. Glad you got it fixed though! |
|
So, putting a scratch variable in <var_struct name="amOkuboWeiss" time_levs="1" packages="amOkuboWeiss"> doesn't work due to the packages tag? This is where I had put it when I meant packages, not in <package name="amOkuboWeiss"... If you look at Registry_okubu_weiss.xml, the variables that are currently in okuboWeissScratch had been in var_struct name="amOkuboWeiss", just with the persistence="scratch" tag. That is what didn't compile in the first place, and then I had tried adding them to <var_struct name="scratch"..., but that created the run time crash during mpas_allocate_scratch_field. |
|
And a little more clarification on the second one, this was my assumption:
Is it not possible to add more variables to an existing var_struct namespace if they live in two different registry files, or do var_struct names need to be unique per registry xml? |
|
Oh, yes. I understand more what you were doing now. I think examples like this would benefit from having the registry files that caused the issues. But you're correct. You can't have the packages tag on a var_struct if the var_struct contains scratch variables. I can add something for us to think about as far as changing this (i.e. a scratch variable ignores packages....) but it can get confusing to deal with quickly, so it's generally easier to just make a hard rule like this. As far as the second issue (defining an additional var_struct with the name scratch), that does work fine. The structures get merged during build time, and the resulting structure contains all fields defined in both of them. I'd have to see what Registry.xml file you tried, what code you tried to run (i.e. with the mpas_allocate_scratch_field), and what the resulting error was to be able to debug what was going on though. |
|
Actually, that’s pretty easy to test. If you take my current branch, and change “okuboWeissScratch” to “scratch” in Registry_okubo_weiss.F, it should crash at the first mpas_allocate_scratch_field call in mpas_ocn_okubo_weiss.F. I verified this by allocating an existing field that exists in “scratch” in Registry.xml. That worked just fine. The scratch variables that I defined in “scratch” var_struct in Registry_okubo_weiss.xml, made it crash at that call. -Jon From: Doug Jacobsen <notifications@github.commailto:notifications@github.com> Oh, yes. I understand more what you were doing now. I think examples like this would benefit from having the registry files that caused the issues. But you're correct. You can't have the packages tag on a var_struct if the var_struct contains scratch variables. I can add something for us to think about as far as changing this (i.e. a scratch variable ignores packages....) but it can get confusing to deal with quickly, so it's generally easier to just make a hard rule like this. As far as the second issue (defining an additional var_struct with the name scratch), that does work fine. The structures get merged during build time, and the resulting structure contains all fields defined in both of them. I'd have to see what Registry.xml file you tried, what code you tried to run (i.e. with the mpas_allocate_scratch_field), and what the resulting error was to be able to debug what was going on though. — |
|
So, were you making the entire var_struct scratch? i.e. changing: to
? If that's the case, then currently framework doesn't allow var_structs to be marked as scratch. Only |
|
No sorry, the name was "scratch," i.e., <var_struct name="scratch"... The variables inside were persistence="scratch" I'll make a branch or a gist tomorrow. I think that will help. Jon From: Doug Jacobsen So, were you making the entire var_struct scratch? i.e. changing: to <var_struct name="okuboWeissScratch" time_levs="1" persistence="scratch"> ? If that's the case, then currently framework doesn't allow var_structs to be marked as scratch. Only <var and <var_array blocks can be marked as scratch. But that just causes all variables within the var_struct to be marked as persistent instead of scratch (assuming they don't have persistence="scratch" themselves). What mesh were you running on when you had that issue? � |
|
Sure. I'd like to see a branch or a gist to test it out. Just a note, if you just change the name to scratch, it won't work in your code, because you're attempting to get the fields from a different pool (that doesn't exist anymore). |
|
Oh good point. I'll make a patch for both cases. Jon From: Doug Jacobsen Sure. I'd like to see a branch or a gist to test it out. Just a note, if you just change the name to scratch, it won't work in your code, because you're attempting to get the fields from a different pool (that doesn't exist anymore). � |
|
Hmm. OK. So, doing the first case, putting scratch variables inside of var_struct name="amOkuboWeiss" failed with this message:
For the second case, putting the variables inside of "scratch," it's working now. I'm finding it to work now at least with 16 cores. I'm scaling it up now to see if it crashes at a higher core count. I will let you know if it works. Though, when I originally tried it, it was based off the 3.2 and I hadn't incorporated 3.3 hotfixes yet. Would there have been something that fixed it since 3.2 to 3.3? |
|
@jonwoodring Thanks for testing this. It sounds like those are both expected results from the tests. I can't think of anything that would have changed this between 3.2 and 3.3, but it's possible. I don't know that it's worth going back and trying to find the issue since it appears fixed, so I'm going to mark this as closed. Let me know if you're like me to open it and look into the problem more. Thanks again for your help! |
…routines This merge replaces the calls to the mpas_pool_get_array_gpu function with calls to mpas_pool_get_array for the routines solve_diagnostics and init_coupled_diagnostics. The gpu calls have !$acc data copyin directives and they transfer the variables on to gpu. The two functions solve_diagnostics and init_coupled_diagnostics are also called outside the time integration. The data copying was corrupting the GPU data later in the timestep, resulting in NaNs. * removal_of_getarray_gpu_call: Removal of mpas_get_array_gpu calls
DESCRIPTION OF CHANGES: Remove warnings (mentioned in ISSUE JCSDA-internal#17) when using the 2-stream initial state in an mpas_atmosphere forecast. LIST OF MODIFIED FILES: M src/core_atmosphere/Registry.xml ISSUES: Closes MPAS-Dev#17 TESTS CONDUCTED: Tested on Cheyenne. No impact.
DESCRIPTION OF CHANGES: Remove warnings (mentioned in ISSUE JCSDA-internal#17) when using the 2-stream initial state in an mpas_atmosphere forecast. LIST OF MODIFIED FILES: M src/core_atmosphere/Registry.xml ISSUES: Closes MPAS-Dev#17 TESTS CONDUCTED: Tested on Cheyenne. No impact.
Generalize pressure constants and make consistent with documentation
* Add support for RAP initial conditions * Add cycled aerosol information to ICs and LBCs * patch for dp=0 problem + some cleanup --------- Co-authored-by: Anders Jensen <anders.jensen@noaa.gov>
fix merge error that removed ruc init
In Registry_okubo_weiss.xml, I had to create a scratch variable in a separately named group that I called "okuboWeissScratch."
The two places that I tried it, that did not work:
I don't know if either one of these are bugs or features.
The text was updated successfully, but these errors were encountered: