-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split TR_GridComp into separate repository #102
Comments
Mentioning @sdeastham as well, as he may have advice if there are issues. |
ETA: Please see below for how I did this for the second TR_GridComp Well, I had some time and wanted something new to try. I think I have a first good go (mainly testing things out). I've made a new TR_GridComp repo that I'm trying out now. I did this following this page using these commands:
That left me with just the TR_GridComp files. Now we push up to the new repo:
I then added a |
This is probably just the first step. Essentially, |
Hi- I wrote the original module, and would like to help in the maintenance (preserving the strengths, and improving its shortcomings). Moving TR into its own module is a good first step. |
Is there still a want to do this? I think the TR_GridComp I made long ago is probably still the same. I'm not sure there has been any updates. |
I think there is still desire. There was still some discussion about the ordering of creating the repo vs refactoring. Arlindo argued it would be best to wait for the code cleanup. But Harvard indicated there was some value in getting the separate repo even in advance of the refactoring. What I don't recall is if there was a subsequent wrinkle that had as hold off, or if we were just waiting for someone to be squeaky enough to trigger the work. |
There have been developments in TR, although some are waiting to be captured from the Icarus version and merged into Jason. I think that Elliot was asked to make TR compliant w/ ESMF best practices, although that would not start until he is done with the GOCART next-gen project. |
Okay! Just wanted to make sure. I can always recreate the repo as TR advances (if needed) |
I am looking into including TR_GridComp in GCHP in the near future. Can you think of any reasons not to work with the new repo as it is now? There is the complication of the dependency on Chem_Shared since Chem_Shared is still in GEOSchem_GridComp. Do you have any plans to address this so that TR_GridComp is more portable? |
@lizziel Well, the main reason is I should probably nuke TR_GridComp and re-make it. I figure once we got to the point that @mmanyin, @gmao-esherman, etc. were ready to split off TR, I could do it and then we'd have a TR with all the right history. I just don't want to split it off and have two TRs floating around in development. That way leads to madness! |
If the repo is in flux I could also copy files temporarily to play with instead. Is there a recommended version of GEOSchem_GridComp to use for this (containing TR_GridComp, Chem_Shared, and Chem_Base that are functional). Ideally we would use it to generate passive tracer data to compare to GEOS ESM and CTM. |
Unfortunately, I'm seeing that this ticket did not capture some conversations that apparently happened by email. Arlindo had recommended that splitting TR wait until Elliot can do the refactoring, but we all agreed that it really does not matter the order so long as we are agreed that it should become a separate repo. In any event - yes I'd prefer to do the repo surgery when TR is down to just one or two branches. I don't think @gmao-esherman has touched this one at all, so if Mike can get all his changes into some sort of develop branch, maybe we are at that point now? |
You are correct. I have not done anything to TR. It would be ideal to have Mike's updates in TR before any refactoring is done. Although I don't think I am supposed to refactor TR anytime soon. |
Following up, I'm not going to bring in TR_GridComp into GCHP until it is more stable in GEOS. If work starts up on it again please put an update on GitHub so I'll see it. Much appreciated! |
Sounds good. I will be sure to update the issue if/when TR gets updated. |
Can this be closed now that TR_GridComp is its own repository, or are you not using it yet in GEOS? I am still interested in bringing it into GCHP and have new direction to do this with TR_GridComp as it is now. I created separate issue https://github.com/GEOS-ESM/TR_GridComp/issues/1 in the new repo GitHub space. |
@lizziel As I said in the other PR, the TR repo was more of a "demonstration". Not yet operational. But we will discuss it internally. |
Sounds good. This came up in an email discussion with Andrea today so please include her in the loop. |
I removed the old TR_GridComp repo and redid this with
and then:
and then I added |
Okay, TR_GridComp Try 2 is now available. It should be pretty simple to remove it here and point GEOS to the new repo when needed. |
It's been a long time coming, but coming soon: As reference, I'm using this as the script: |
@mathomp4 feel free to outsource the details to others on SI team. Consult @christophkeller for any questions about any needed changes to directory structure and/or copying of dependencies in Chem_Base.
I've told GCHP that this could probably be done in ~ 1 week but that the SI team is very busy and this is lower priority, albeit easy.
The text was updated successfully, but these errors were encountered: