Bugfixes/jstassi/#185/fvsetup #186
Conversation
gmao-jstassi
commented
Jun 3, 2022
gmao-jstassi
commented
- setenv ARCHIVE in the fstats_run script, so that the script can be run in an environment where ARCHIVE is not defined correctly for the experiment
- change "tail +2" syntax to "tail -n +2"
… to correct tail +2 syntax error (changed to tail -n +2).
…up script, so that the *.input files can be run using the runjob script. The codeID values were also updated, but these are not currently being used for anything.
gmao-jstassi
added
0 diff
There was a problem hiding this comment.
Hi Joe,
I truly think the approach of updating the codeID by hand is a doomed approach. If we are going to have to do this for every change we make it will be a nightmare. We have to find a way for this information to be picked up the fly.
I don't mind approving your changes - the real fix in fvsetup is relevant; the others ones ... not sure - as I say, I don't mind taking them, but that information will fall behind again in no time.
|
Ricardo, the codeID and fvsetupID values are updated with the update_input_IDs.pl script, so it is not completely by hand. The codeID value is not used for anything, so the only time these values need to be changed is when fvsetup is updated. I agree that it would be nice if this could be automated. I will look into it. |
|
Hi Joe, I see that you are wiring in the git ref git (tag) in the input files ... this is a bit of a nightmare. We need to find a way to centralize this somehow and not have to change each and every one of these files just because we made a new commit to GEOSadas fixture that has nothing to do w/ the input files. Can you think of something? I will take these as they are here for now, but as soon as I put another change to develop this will fall out of sync. Sorry - I see you had answered a similar comment I made on this before ... still, my comment is valid. We need a solution for this. |
|
@rtodling I can say it is possible to fill these in at CMake time. With the right code, CMake can figure out what the git commit of its own source code is and then fill that in. For example, if I add to the GEOSgcm find_package(GitInfo)
GIT_WC_INFO(${CMAKE_CURRENT_SOURCE_DIR} GEOSgcm)this will fill in a bunch of variables as defined in the include(CMakePrintHelpers)
cmake_print_variables(GEOSgcm_WC_REVISION_HASH)
cmake_print_variables(GEOSgcm_WC_REVISION)
cmake_print_variables(GEOSgcm_WC_REVISION_NAME)
cmake_print_variables(GEOSgcm_WC_URL)
cmake_print_variables(GEOSgcm_WC_ROOT)
cmake_print_variables(GEOSgcm_WC_LAST_CHANGED_DATE)
cmake_print_variables(GEOSgcm_WC_LATEST_TAG)
cmake_print_variables(GEOSgcm_WC_LATEST_TAG_LONG)then at CMake time we see: You could use this in combination with |
|
Ricardo,
It is not as bad as you think.
The reason I updated the ID values in the input files for this PR is because I modified the fvsetup script.
I did not update the input files individually. There is a utility script in the GEOSdas_App/testsuites directory called update_input_IDs.pl which updates all the input files at once. It even finds the needed values for you, so it is very easy. You should try it.
Here is an explanation of the ID values in the input files:
The input files have two IDs, codeID and fvsetupID. The codeID is set to a GIT_TAG_OR_REV variable that Matt created to replace the CVS TAG info when we converted to git. Currently, codeID is not used for anything, and I have considered removing this variable from the input files.
The fvsetupID is the git ref ID for the fvsetup script. This value is used for comparison between the runjob script and the input file. The idea is that if fvsetup has changed, then the prompts may not match those in the input files. All we really care about is updates to fvsetup. We don't care about any other updates in the system.
So the only time the ID values in the input files need to be updated is when fvsetup is modified, and even then it is not critical, because the runjob script will give the user the option to continue, even if the IDs don't match.
What we could do is only update the ID values when there is a new tag or release. Then we won't be doing any more work than what we did when we were using CVS, and it will actually be easier because of the update_input_IDs.pl utility.
If you still have questions about this, then let me know.
Joe
…________________________________
From: rtodling ***@***.***>
Sent: Thursday, July 21, 2022 12:43 PM
To: GEOS-ESM/GEOSadas ***@***.***>
Cc: Stassi, Joe (GSFC-610.1)[SCIENCE SYSTEMS AND APPLICATIONS INC] ***@***.***>; Author ***@***.***>
Subject: [EXTERNAL] Re: [GEOS-ESM/GEOSadas] Bugfixes/jstassi/#185/fvsetup (PR #186)
Hi Joe,
I see that you are wiring in the git ref git (tag) in the input files ... this is a bit of a nightmare. We need to find a way to centralize this somehow and not have to change each and every one of these files just because we made a new commit to GEOSadas fixture that has nothing to do w/ the input files. Can you think of something? I will take these as they are here for now, but as soon as I put another change to develop this will fall out of sync.
—
Reply to this email directly, view it on GitHub<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FGEOS-ESM%2FGEOSadas%2Fpull%2F186%23issuecomment-1191711745&data=05%7C01%7Cjoe.stassi%40nasa.gov%7C5df56649e1304f39a82608da6b381783%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637940185902492946%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Cb2JA8eFoGccbrRmbQUYcbDFHHks%2BIIWSa6z2AZmAO0%3D&reserved=0>, or unsubscribe<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAMBAJ2QHCYCR3ROB6PVJGDLVVF4ZTANCNFSM5XZ4G5ZQ&data=05%7C01%7Cjoe.stassi%40nasa.gov%7C5df56649e1304f39a82608da6b381783%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637940185902492946%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=l9gIlVzvJnYkYvZQiQfavC251cdEVOOyAbgi5092yRI%3D&reserved=0>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
