Closed TonyB9000 closed 4 months ago
TonyB9000
commented
4 months ago @chengzhuzhang Although I created a separate branch for this "end-to_end" update, it still includes all of the other changes pushed for the "consolidate_cmor_setups_and_logging" PR. I guess I should have done a complete "git-clone" of the repo for this branch, to keep things separate?
Let me know if/how I should do things differently here. (Or any actions you would like me to take at this point.)
chengzhuzhang
commented
4 months ago @TonyB9000 for a new feature branch, it should base from the master branch. In your case, no git-clone is needed, you can checkout the master branch, do a git pull origin master to make sure your local branch is updated with remote. Then make a new branch with the updated end to end script, so that the branch won't include changes from the cmor updates PR. Does it make sense? Otherwise, we can live with this. But please do make sure next time to checkout new branch start from master.
TonyB9000
commented
4 months ago @chengzhuzhang I can (and should) do this, just to become exercised in this.
When I do a "checkout master" (to switch to the master branch) and then "git pull origin master", I have what is essentially the "git clone" version of master - uncontaminated with the changes made to either branch - is that correct?
Should I next "checkout update_end_to_end", (the existing new branch), or should I "checkout -b (brand_new_named_branch)" and copy over the updated script E2E script? (and destroy/abandon the previous E2E branch?)
Lastly, if I later "checkout" and add new changes to the cmor-updates branch (and it has the older end-to-end script), I won't "git add" the new end-to-end (will it even be there?) and I won't lose or clobber the E2E update.
Am I close?
chengzhuzhang
commented
4 months ago @chengzhuzhang I can (and should) do this, just to become exercised in this.
When I do a "checkout master" (to switch to the master branch) and then "git pull origin master", I have what is essentially the "git clone" version of master - uncontaminated with the changes made to either branch - is that correct?
Yes, it is correct.
Should I next "checkout update_end_to_end", (the existing new branch), or should I "checkout -b (brand_new_named_branch)" and copy over the updated script E2E script? (and destroy/abandon the previous E2E branch?)
One solution is to copy out the E2E script somewhere outside of the repo path (so that it won't get lost), and copy over you when you "checkout -b (brand_new_named_branch)". Can issue a new PR and abandon this one.
Lastly, if I later "checkout" and add new changes to the cmor-updates branch (and it has the older end-to-end script), I won't "git add" the new end-to-end (will it even be there?) and I won't lose or clobber the E2E update.
I think cmor-updates is on a different branch, so i suppose it won't have the E2E update. Am I close?
TonyB9000
commented
4 months ago @chengzhuzhang "I think cmor-updates is on a different branch, so i suppose it won't have the E2E update"
I think you're right. Hard to keep this branch stuff straight in my head.
chengzhuzhang
commented
4 months ago Close, in favor of #264
Description
This is a feature addition to the example_end_to_end_script.sh". The final section (mpaso CMIP generation) has been wrapped in codes that loop over the e2c call for each specified YPF segment of years. The total years are still calculated by examining the user-supplied "model-output" directory, but now an intermediate directory (native_links) is employed, keeping the links to restart, namefile and regions-file, but creating (and destroying) symlinks to the datafiles, by YPF segment.
Changes have only been tested in "dry-run" (where the actual e3sm_to_cmip command is commented out) in order to test the YPF cycling (and logfile generation) alone.