GFDL_atmos_cubed_sphere
GFDL_atmos_cubed_sphere copied to clipboard
NOAA-GFDL
on dev/gptl branch, missing dependency atmos_co2_mod
I first encountered this on master, now also on the dev/gptl branch. (I have not tried dev/emc yet).
The directory driver/GFDL contains one .F90 file: atmosphere.F90. It contains:
use atmos_co2_mod, only: atmos_co2_rad, co2_radiation_override
The atmos_co2_mod is not in GFDL_atmos_cubed_sphere, nor is it in FMS. (As pointed out by @wrongkindofdoctor it comes from the atmos_shared/tracer_driver subdirectory of the AM4 repo. See the discussion in closed PR 2 https://github.com/NOAA-GFDL/GFDL_atmos_cubed_sphere/pull/2).
So apparently this is a mod file you guys are building elsewhere and have installed, and this dependency has crept in. Choices include: 1 Provide a build system for AM4 and require AM4 be built before FV3 is built. (This would capture the current situation). 2 Move atmos_co2_mod to FMS. 3 Create a new library, which includes atmos_co2 and is linked to by both AM4 and GFDL_atmos_cubed_sphere. 4 Copy the atmos_co2_mod code in both AM4 and GFDL_atoms_cubed_sphere.
@bensonr would welcome guidance here. Personally, I can do 1 (if AM4 will accept a build system), and can help with any of the others, given guidance.)
This issue will be updated once QA of this branch as a submodule for the NOAA-GFDL/AM4 and NOAA-GFDL/CM4 projects is complete. Option 1 will be the mechanism for using the dev/gfdl branch and the README.md will be updated to be more explicit.
Please see the https://github.com/NOAA-GFDL/AM4.git for a working codebase using the latest dev/gfdl branch (tagged with AM4.0).
I will leave this issue open for now.
@bensonr can I contribute an autotools build system for the AM4?
If so, then it seems that we could easily get the FV3 build system working. Over time, as these interdepencency issues are resolved, it will be easy to unwind the build system so that FV3 will no longer depend on AM4. Yet the build systems for both will remain, and continue to bring value.
Does this sound OK to you?
Sounds good to me. I don't foresee objections to an autotools build for AM4.
On Mon, Jul 29, 2019 at 2:56 PM Edward Hartnett [email protected] wrote:
@bensonr https://github.com/bensonr can I contribute an autotools build system for the AM4?
If so, then it seems that we could easily get the FV3 build system working. Over time, as these interdepencency issues are resolved, it will be easy to unwind the build system so that FV3 will no longer depend on AM4. Yet the build systems for both will remain, and continue to bring value.
Does this sound OK to you?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NOAA-GFDL/GFDL_atmos_cubed_sphere/issues/3?email_source=notifications&email_token=ABSKBVCZGIOJ6NTOYZHRVCDQB44PPA5CNFSM4IHFG5M2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3BVTCQ#issuecomment-516118922, or mute the thread https://github.com/notifications/unsubscribe-auth/ABSKBVFRTVWYMCIQYAVV75DQB44PPANCNFSM4IHFG5MQ .
OK, I contributed a build system for AM4, but that also is bogged down in missing dependencies. What a tangled web we weave, when we attempt to use home-rolled build systems!
Is there a way to build this project, without AM4?
If not, is there a plan for getting to a state of being any to build this project without AM4?
Hi, Edward. FV3 is a dynamical core and not a model. There is no capability to compile FV3 as a stand-alone executable, and needs to be compiled within a model such as AM4, SHiELD, or the UFS.
Lucas
Sent from my iPhone
On Dec 30, 2019, at 8:31 AM, Edward Hartnett [email protected] wrote:
OK, I contributed a build system for AM4, but that also is bogged down in missing dependencies. What a tangled web we weave, when we attempt to use home-rolled build systems!
Is there a way to build this project, without AM4?
If not, is there a plan for getting to a state of being any to build this project without AM4?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
In that case I would expect it to be a library, which could be compiled and tested without a model. Is that a more accurate way to look at it?
What we want is to be able to run tests on this repo using Travis or some other continuous integration (CI) system. In order to do that, we need to be able to check it out, build it, and run some tests.
So it must build in a stand-alone mode, even if it is not used that way in a model. In exactly the same way, netCDF is built and tested, even though it is used within the model.
Hi, Edward. I don't know. You would need to ask a software engineer as to testing FV3 as a library.
Lucas
On Mon, Dec 30, 2019 at 11:24 AM Edward Hartnett [email protected] wrote:
In that case I would expect it to be a library, which could be compiled and tested without a model. Is that a more accurate way to look at it?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/NOAA-GFDL/GFDL_atmos_cubed_sphere/issues/3?email_source=notifications&email_token=AMUQRVELB25VUBHCMSUG7KDQ3IOFLA5CNFSM4IHFG5M2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH2U4XI#issuecomment-569724509, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMUQRVAB7EZCMSXLW57EMNDQ3IOFLANCNFSM4IHFG5MQ .
Awesome, because I'm a software engineer. ;-)
So let me rephrase this: How about I submit a build system plus a mock-up of the missing pieces which builds only when the project is tested?
This way, GFDL_atmos_cubed_sphere can be checked out, built, and tests run. When it is built as part of one of your models, it uses the pieces from the model.
Probably this would be accomplished with an extra configure option --enable-test-build.
With a CI system in place, going to close this. I understand the CI system doesn't test individual pieces, but instead idealized analytic solutions. The DSL version of FV3 does have support for true functional unit tests.