Predefined dynamicmask

[bena-nasa]

Creating PR for discussion of predefined dynamic masking as discussed in last GMAO/ESMF meeting

[theurich]

From looking through the file changes, I see one minor whitespace change that should be reverted. Other than that, I do have more high level design questions... which I will write up as a general comment in the conversation of the PR.

[theurich]

This whitespace change should be reverted.

[theurich]

@bena-nasa @oehmke @tclune - I reviewed this PR, and I have a very high level design question. Basically I am wondering why optional arg of type ESMF_PredefinedDynamicMask enters the methods that handle dynamic masking, i.e. ESMF_ArraySMM() and ESMF_FieldRegrid(). I would have naively thought that the ESMF_PredefinedDynamicMask class is used to generate an ESMF_DynamicMask object, which then can be passed into the unmodified existing methods mentioned above as usual. Maybe I am missing something about the actual use case, and why it necessitates the proposed, more integrated changes. I am sorry if this design aspect has already been discussed and I missed it.

[bena-nasa]

@bena-nasa @oehmke @tclune - I reviewed this PR, and I have a very high level design question. Basically I am wondering why optional arg of type ESMF_PredefinedDynamicMask enters the methods that handle dynamic masking, i.e. ESMF_ArraySMM() and ESMF_FieldRegrid(). I would have naively thought that the ESMF_PredefinedDynamicMask class is used to generate an ESMF_DynamicMask object, which then can be passed into the unmodified existing methods mentioned above as usual. Maybe I am missing something about the actual use case, and why it necessitates the proposed, more integrated changes. I am sorry if this design aspect has already been discussed and I missed it.

The idea was that this would be something usable from python, via the C wrappers eventually. Since there is no dynamic masking option for the C interface to regrid that was one issue. The other issue is that right now to create dynamic mask you have to pass a Fortran procedure reference which would not be possible from python.

If we were just sticking to the Fortran API only then I agree with your analysis that what I've done here is overkill and what you propose would make more sense.

That said, I'm no expert in C so maybe I've overlooked something.

[theurich]

The way I am thinking about this wrt C and Python interfaces is that we will expose the ESMF_DynamicMask class. It would be done similar to any other shallow ESMF class. We will NOT expose the current ESMF_DynamicMaskSet*() methods, which all take the dynamicMaskRoutine as required argument, and as you say, those don't make much sense on the C or Python level. Instead predefined dynamic masks are implemented on the Fortran side via a set of additional ESMF_DynamicMaskSet*() methods with required argument of type(ESMF_PredefinedDynamicMask), and those routines, as well as shallow class ESMF_PredefinedDynamicMask, are exposed to the C and Python API.

Does that make sense?

Thinking about it some more, we might not even really need the extra ESMF_PredefinedDynamicMask class. It woudl seem that additional ESMF_DynamicMaskSet*() methods I mentioned above could just directly take in the ESMF_PredefinedDynamicMask_Flag you have defined, and any additional info, to set up a predefined dyn mask. Seems pretty straight forward and clean.

[bena-nasa]

@theurich I think I understand what you are saying and seems cleaner. I just have to wrap my head around the nuts and bolts. I'll look through the code try to understand how you expose some of these Fortran classes to C, but what would be perhaps the best example of another shallow ESMF class that you expose to the C (and therefore the python) interface that I could look at as an example? Maybe something like the time class?

[theurich]

@bena-nasa e.g. look at ESMF_ArraySpec, and how it is routed through to the C API as ESMC_ArraySpec. You will see that it is first routed through to the C++ layer as ESMCI::ArraySpec, and then the C API is based on top of that.

[bena-nasa]

@bena-nasa e.g. look at ESMF_ArraySpec, and how it is routed through to the C API as ESMC_ArraySpec. You will see that it is first routed through to the C++ layer as ESMCI::ArraySpec, and then the C API is based on top of that.

So the C API, routes through a C++ layer which is denoted by all the files that are named ESMCI, them from the C++ layer you are calling into the Fortran layer?

Is that general pattern? And can you say something about this FTN_X function?

[theurich]

Yes, that is the general pattern. Files that start with ESMC_ should use strict C99 syntax, no C++. The C++ layer is implemented in files with ESMCI_ prefix (the I stand for "internal" - but that is a bit historical, it's the C++ internal layer).

The FTN_X() is a CPP (preprocessor) macro function that ensures the correct name mangling when calling from C++ into Fortran functions.

[bena-nasa]

Where is that FTN_X defined out of curiosity? I can't seem to find it. Also I was looking through the developers guide and saw this remark
"ESMF is written in a combination of C/C++ and Fortran. Techniques used in ESMF for interfacing C/C++ and Fortran codes are described in the ESMF Implementation Report[#!bib:ESMFimplrep!#], which is available via the Users tab on the ESMF website. These techniques, which address issues of memory allocation, passing objects across language boundaries, handling optional arguments, and so on, are general and have been applied to multiple projects."

Does this report still exist?

[oehmke]

I was curious, so I dug into some of the usual spots for this kind of thing in ESMF. It’s defined per compiler under <ESMF_DIR>/build_config

…

On Feb 18, 2025, at 3:05 PM, Ben Auer ***@***.***> wrote: bena-nasa left a comment (esmf-org/esmf#350) Where is that FTN_X defined out of curiosity? I can't seem to find it. Also I was looking through the developers guide and saw this remark "ESMF is written in a combination of C/C++ and Fortran. Techniques used in ESMF for interfacing C/C++ and Fortran codes are described in the ESMF Implementation Report[#!bib:ESMFimplrep!#], which is available via the Users tab on the ESMF website. These techniques, which address issues of memory allocation, passing objects across language boundaries, handling optional arguments, and so on, are general and have been applied to multiple projects." Does this report still exist? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned. <#350 (comment)> <https://github.com/notifications/unsubscribe-auth/AE6A7U5QW2G2WC3PTB3QVUD2QOVCRAVCNFSM6AAAAABWICERJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRXGAZDONRWG4> bena-nasa left a comment (esmf-org/esmf#350) <#350 (comment)> Where is that FTN_X defined out of curiosity? I can't seem to find it. Also I was looking through the developers guide and saw this remark "ESMF is written in a combination of C/C++ and Fortran. Techniques used in ESMF for interfacing C/C++ and Fortran codes are described in the ESMF Implementation Report[#!bib:ESMFimplrep!#], which is available via the Users tab on the ESMF website. These techniques, which address issues of memory allocation, passing objects across language boundaries, handling optional arguments, and so on, are general and have been applied to multiple projects." Does this report still exist? — Reply to this email directly, view it on GitHub <#350 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE6A7U5QW2G2WC3PTB3QVUD2QOVCRAVCNFSM6AAAAABWICERJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRXGAZDONRWG4>. You are receiving this because you were mentioned.