Executable to rule them all

[danholdaway]

Changes e.g. fv3jedi_variational.x config.yaml -> gdas_fv3jedi.x variational config.yaml. Do we like this?

Pros:

• Build only executables we need.
• Is this better NCO compliance?
• Don't waste time building tests for fv3-jedi and soca.

Cons:

• Maintenance increase.
• Needs G-W changes.

[danholdaway]

Building wont work in the tests because the executables can't be made

[aerorahul]

Why not go one step further and have:

gdas_jedi.x fv3jedi variational config.yaml

or

gdas_jedi.x soca hofx config.yaml

One executable to rule them all!

[guillaumevernieres]

I like it :+1: . That would also give us the flexibility to add some of the pre-and post processing tasks within the same executable too.

[guillaumevernieres]

FYI @danholdaway , this could be tested with soca without a PR in the g-w. We haven't updated our agricultural script that runs the variational application yet.

[danholdaway]

Why not go one step further and have:

gdas_jedi.x fv3jedi variational config.yaml

or

gdas_jedi.x soca hofx config.yaml

One executable to rule them all!

I agree that that would be quite nice. Is that still NCO compliant? The line "divide the source files into sub-directories according to the executable they produce" makes it sound like they want separate executables for the gw/sorc/gdas/sorc/code directories. Let me also check that it doesn't make for very massive executables.

[CoryMartin-NOAA]

No I think the most NCO compliant solution as I interpret it is one giant gdas.x

[danholdaway]

No I think the most NCO compliant solution as I interpret it is one giant gdas.x

Ok great, I'll try that out. By the way when I tested this I was expecting to find only gdas_code.x in the bin directory but the cmake on JEDI bundle fills the /bin directory with Python "executables". Something perhaps to keep in mind since right now we can't stop that from happening and that might cause some consternation from NCO.

[aerorahul]

No I think the most NCO compliant solution as I interpret it is one giant gdas.x

Ok great, I'll try that out. By the way when I tested this I was expecting to find only gdas_code.x in the bin directory but the cmake on JEDI bundle fills the /bin directory with Python "executables". Something perhaps to keep in mind since right now we can't stop that from happening and that might cause some consternation from NCO.

I would suggest we work on make install capability and would only install whats built. Additionally, only required executables and python codes should be built. Python code is "technically" not a compiled executable, however, it is being "configured" at build time. We will need to think about what the "install" target for this is pre-code handoff.

[CoryMartin-NOAA]

@danholdaway I fully expect to not even include the python iodaconv repo when this gets implemented. I suspect we will only be using compiled code for conversion then.

[aerorahul]

Why not go one step further and have:

gdas_jedi.x fv3jedi variational config.yaml

or

gdas_jedi.x soca hofx config.yaml

One executable to rule them all!

I agree that that would be quite nice. Is that still NCO compliant? The line "divide the source files into sub-directories according to the executable they produce" makes it sound like they want separate executables for the gw/sorc/gdas/sorc/code directories. Let me also check that it doesn't make for very massive executables.

In this case, we will be linking one gdas_jedi.cd to one gdas_jedi.x as opposed to the numerous ones for each application (e.g. fv3jedi_variational.x, soca_hofx.x, etc.). In that way, it is no different, but provides a single entry point to all functions. It also is in the same vein as running an executable with a different configuration provided by a namelist.

[danholdaway]

g-w PR https://github.com/NOAA-EMC/global-workflow/pull/2565

[danholdaway]

Ready for final review along with global workflow PR

[danholdaway]

Thanks all. What a day, my first contribution to GDASapp 🥹