You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In both set_surface_forcing and its associated diagnostics routine, we have large associate statements that include blocks of code pointing at specific elements of arrays. For example
As we move to a more flexible codebase, it is possible that some of these surface_forcing_ind elements will be 0 (if, for example, we want to run without the "alternate CO2" computations, surface_forcing_ind%xco2_alt_co2_id=0). I thought we ran into an issue at one point where a compiler complained about associating to something out of the bounds of the array, but I don't remember the specifics... so I'm creating this issue ticket as a place to leave comments if it comes up again.
I believe @klindsay28 is working on a branch of the code where surface_forcing_ind%iron_flux_id=0 - can you please leave a comment and let us know if any of the big three compilers (Intel, GNU, NAG) complains?
Two possible work-arounds:
Nested associate statements (would need to see how compilers react to that, as well)
Pointers instead of associate statements (would need to set up target attribute in a lot of data types)
The text was updated successfully, but these errors were encountered:
In both
set_surface_forcing
and its associated diagnostics routine, we have large associate statements that include blocks of code pointing at specific elements of arrays. For exampleAs we move to a more flexible codebase, it is possible that some of these
surface_forcing_ind
elements will be 0 (if, for example, we want to run without the "alternate CO2" computations,surface_forcing_ind%xco2_alt_co2_id=0
). I thought we ran into an issue at one point where a compiler complained about associating to something out of the bounds of the array, but I don't remember the specifics... so I'm creating this issue ticket as a place to leave comments if it comes up again.I believe @klindsay28 is working on a branch of the code where
surface_forcing_ind%iron_flux_id=0
- can you please leave a comment and let us know if any of the big three compilers (Intel, GNU, NAG) complains?Two possible work-arounds:
target
attribute in a lot of data types)The text was updated successfully, but these errors were encountered: