Multiple instances

[pcolarco]

@mathomp4 Matt, would you have a look at feature/pcolarco/multiple_instance against current GOCART develop?

What I am trying to do is introduce flexibility to declare additional "instances" of an aerosol child that would be, for example, regionally tagged or source tagged species. I attempt this by adding the specific emission pointer names to the instance *.rc files, and then parse those and assign to IMPORT pointers in the code. Much more flexibly than doing it by hand. It requires any new IMPORTs be added to StateSpecs and ExtData.yaml and code being recompiled, but should not have to further touch the fortran.

My specific question is about how I handle the assignment of the IMPORT name from the instance.rc file to variables. I created a couple of local subroutines to do this...get the name from the resource file, check if /dev/null (in which case allocate the emission variable and assign = 0), else get from the IMPORT state. I did this for a 2d and a 3d emission file in two separate routines, but maybe could be done in one? And probably this should be moved up to GOCART2G level so I don't duplicate in every child component.

Thanks!

[mathomp4]

@pcolarco I took a look at the differences:

https://github.com/GEOS-ESM/GOCART/compare/develop...feature/pcolarco/multiple_instance?w=1

and it seems okay to me at first glance. If it builds and runs, that's most important.

I'll mention @bena-nasa and @tclune to see if they have any thoughts.

[tclune]

Looks fine to me. The salient point is that arrays and names (strings) are associated via MAPL_GetPointer() It is merely a convention that the array name reads the same as the string name, and when the string must vary at runtime (comes from resource file) then the convention clearly is inapplicable. Instead the name of the string variable should correlate with the name of the array. And that is what has been done here.

[pcolarco]

Thank you both for your comments. I tried it out and ensured zero-diff with the carbon component (there’s a couple of twitchy things I need to work through to do with the unused but still filled in aerosol deposition bundle) and am extending to the other species now. Pete From: Tom Clune ***@***.***> Date: Wednesday, October 30, 2024 at 12:49 PM To: GEOS-ESM/GOCART ***@***.***> Cc: Colarco, Peter R. (GSFC-6140) ***@***.***>, Mention ***@***.***> Subject: [EXTERNAL] [BULK] Re: [GEOS-ESM/GOCART] Multiple instances (Discussion #295) CAUTION: This email originated from outside of NASA. Please take care when clicking links or opening attachments. Use the "Report Message" button to report suspicious messages to the NASA SOC. Looks fine to me. The salient point is that arrays and names (strings) are associated via MAPL_GetPointer() It is merely a convention that the array name reads the same as the string name, and when the string must vary at runtime (comes from resource file) then the convention clearly is inapplicable. Instead the name of the string variable should correlate with the name of the array. And that is what has been done here. — Reply to this email directly, view it on GitHub<#295 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANW73YFZAMIWIP5XGWABODDZ6EE2NAVCNFSM6AAAAABQ2TM4FKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMJQGI3TQOA>. You are receiving this because you were mentioned.Message ID: ***@***.***>