Add skeleton fab script - #246
Conversation
…nfiguration to compile skeleton.
|
This PR only adds a command-line build system using Fab for the Skeleton apps. It is not at all integrated into cylc or any other test suite. Tests have been added to the infrastructure/build/fab scripts which cover the newly added infrastructure files there. Some unit tests are based on some AI input to setup the frame work, but have been manually tweaked to ensure code coverage. Documentation is in form of a README in the above directory, please let me know if you want me to add more elsewhere. |
Matthew Hambley (MatthewHambley)
left a comment
There was a problem hiding this comment.
I note that a lot of requests made in the original review on SRS have not been addressed so for convenience I have repeated them here.
I note that all my comments and questions to your original reviews (as originally agreed a few months ago on MetOffice/lfric-baf#83) have not been addressed so for convenience I will repeat them here. It will take me a while to get through all your comments, but I will start adding comments now, so ideally we can discuss some of the issue and reach an agreement while I still work on other comments. |
Matthew Hambley (MatthewHambley)
left a comment
There was a problem hiding this comment.
This change represents an initial implementation on which we can build.
Sam Clarke-Green (t00sa)
left a comment
There was a problem hiding this comment.
Thanks, looks good. See comments inline for minor changes.
| return | ||
|
|
||
| if gfortran.get_version() < (4, 9): | ||
| raise RuntimeError(f"GFortran is too old to build dynamo. " |
There was a problem hiding this comment.
Minor name change:
| raise RuntimeError(f"GFortran is too old to build dynamo. " | |
| raise RuntimeError(f"GFortran is too old to build LFRic. " |
There was a problem hiding this comment.
Done.
| ## Setting up Site- and Platform-specific Settings | ||
| Site- and platform-specific settings are contained in | ||
| ```$LFRIC_CORE/infrastructure/build/site-specific/${SITE}-${PLATFORM}``` | ||
| The default settings are in ```.../site-specific/default``` (and at this |
There was a problem hiding this comment.
| The default settings are in ```.../site-specific/default``` (and at this | |
| The default settings are in ```../site-specific/default``` (and at this |
There was a problem hiding this comment.
Hmm - I have to admit I don't like this: .. indicates the parent directory, so I fear that this might be understood as site_specific being lfric_core/site_specific, while it is in lfric_core/lfric_build/site_specific.
What about removing the .../ entirely ("... are in site_specific/default"). Or "are in $LFRIC_CORE/lfric_build/site-specific" instead?
There was a problem hiding this comment.
For now I've removed the ``.../```, hope that's a good compromise.
| and use the following command: | ||
|
|
||
| ``` | ||
| ./fab_skeleton.py --nprocs 4 --site nci --platform gadi --suite intel-classic |
There was a problem hiding this comment.
This should probably be a more generic example. Site flags should be documented separately if they are not required.
| ./fab_skeleton.py --nprocs 4 --site nci --platform gadi --suite intel-classic | |
| ./fab_skeleton.py --nprocs 4 |
There was a problem hiding this comment.
Hmm - I don't like removing this entirely, since it would often end up in using gfortran, while sites might expect intel compiler to be used (if no compiler is specified, fab will pick the first available one in its internal list, which is alphabetically sorted). So, I took --site and --platform out, but left the --suite in, together with a list of the default valid suite names.
Then I added a paragraph to discuss the site-specific setup (which will likely be required, since libraries will likely need additional flags). I hope that's ok.
There was a problem hiding this comment.
This is not required. Please delete.
There was a problem hiding this comment.
Done.
| self.setup_gnu(build_config) | ||
| self.setup_nvidia(build_config) | ||
| self.setup_cray(build_config) | ||
|
|
There was a problem hiding this comment.
All the lfric applications currently require netCDF. Would be a good point to check whether any netcdf flags are set and trigger an immediate error rather than waiting for the linker to fail?
There was a problem hiding this comment.
Difficult question. Yes, everything needs NetCDF. But the default setup will create a netcdf entry (based on nf-config, though some sites might overwrite this due to issues with nf-config on Crays). So, each linker will have a netcdf entry.
We could test if an entry for netcdf is empty (i.e. no flags), which happens when nf-config is not available. BUT, not specifying flags for NetCDF is de-facto valid on Cray systems (I assume that is still the case, that loading the netcdf module will automatically add the required include and linking flags).
Additionally, typically an application will not explicitly specify a linker (in which case the linking step will pick a linker based on compiler-suite, mpi flags and language of the main program, i.e. Fortran or C). So, before doing the analysis step we will likely not even know which linker to use (since only the analysis step will determine program units).
Now, this is a lot of theoretical thinking of setups, which will likely not happen (I can't see a good reason to link with any LFRic apps with a C compiler wrapper). I checked, on ncas_ex we hard-coded explicit libraries for NetCDF (since nf-config there did not work). So, I've added the test that you recommended, which will abort before starting the actual work.
|
I've addressed the issues raised here (though in some cases differently, and am happy to discuss). Brought up to current main; ready for next review. |
|
Can you go through and add copyright headers to all the files that need them? |
Sam Clarke-Green (t00sa)
left a comment
There was a problem hiding this comment.
I've added some suggestions based on changes to the UM versions of similar files.
Co-authored-by: Sam Clarke-Green <74185251+t00sa@users.noreply.github.com>
Co-authored-by: Sam Clarke-Green <74185251+t00sa@users.noreply.github.com>
Co-authored-by: Sam Clarke-Green <74185251+t00sa@users.noreply.github.com>
Co-authored-by: Sam Clarke-Green <74185251+t00sa@users.noreply.github.com>
Thanks, done. I did notice that there seems to be two different templates, one with year, one without. I used the one with year, not sure what you prefer. |
All applied, thanks a lot!! |
Sam Clarke-Green (t00sa)
left a comment
There was a problem hiding this comment.
Looks good. Approved
Sam Clarke-Green (t00sa)
left a comment
There was a problem hiding this comment.
Re-approving.
PR Summary
Sci/Tech Reviewer: Matthew Hambley (@MatthewHambley)
Code Reviewer: Sam Clarke-Green (@t00sa)
Adds a first Fab build script for Skeleton. To keep this change minimal, it's command line only (i.e. no cylc integration, which can come later).
Code Quality Checklist
Testing
trac.log
Security Considerations
Performance Impact
AI Assistance and Attribution
Documentation
PSyclone Approval
Sci/Tech Review
(Please alert the code reviewer via a tag when you have approved the SR)
Code Review