Suggest splitting fv3 developments into a dedicated fv3 branch

[guoqing-noaa]

As we update RDASApp to use MPAS v8.2 and MPASJEDI v3.0 (issue #154), we will update quite a few submodule components and the fv3 part will be affected by this update. So we will need to spend efforts to make sure this part work as well. This is not convenient as most GSL developers will not work on the fv3 part.

I would suggest we split the fv3 part into a dedicated 'fv3' branch, keeping fv3 updates separate from the mpas part and we still share the same repo, observation, etc. I would think this will accelerate the mpasjedi development.

[guoqing-noaa]

To add to this:
Using a dedicated fv3 branch based on the current RDASApp will enable us to continue important fv3 testing work.
The fv3 developers can update this branch as needed without worrying about affecting the mpasjedi part.

The current develop branch will be expected to serve the mpasjedi part only going forward and the mpas developers can update this branch as needed without worrying about affecting the fv3 part.

In this way, we can get the best of the two parts and each has its own dependencies. This also eliminates the need to keep all the submodule components exactly the same between MPASJEDI and FV3JEDI. This will speed up the cloning, building and the whole mpasjedi development.

[delippi]

Hi @guoqing-noaa, I see your point about separating the FV3 part into its own branch to avoid some conflicts, but maintaining two separate branches could introduce more problems down the road. It seems to me we should maintain consistency between both versions. Could you clarify which submodule components are affected and how much effort it would require to update them? I can rerun some of my FV3-JEDI validation, if needed. Having the FV3-JEDI baseline (that has been validated against GSI) is such a crucial part that links the work you are doing in MPAS-JEDI to GSI.

[guoqing-noaa]

@delippi Thanks for the discussion!

Do you really need to sync the latest FV3 components to continue the hofx validation? I had thought the current RDASApp serves that purpose enough.

We do have limited resources (at least on the GSL side) and may not be able to support always syncing the fv3 component along with the MPAS components.

Maybe we can have another option?
We can carry over the fv3 part, but all PRs making changes on the mpasjedi side should only need to make sure mpas tests passed and then it can be merged. Anyone who wants to update fv3 components can create a follow-up PR to do that.
And any fv3 updates should make sure the mpas parts don't break.

[ShunLiu-NOAA]

@guoqing-noaa Let's keep fv3 components on the current branch. We are not formally transitioning to MPAS now. Also, once MPAS-JEDI workflow is build up, we have to do a validation work on with FV3 and GSI. The time to remove fv3 components should be when validation is completed. However, we should examine this issue in a couple of months based on MPAS-JEDI progress.

[guoqing-noaa]

@ShunLiu-NOAA Thanks for the input.
Yes, we may have different priorities at the moment. But GSL folks have been fully transitioned to MPAS.
From the current progress, it is a tough task to get a prototype cycling MPAS+JEDI run for the SFE2025 evaluation.

I understand the importance and usefulness of Donnie's hofx validation work, but, (correct me if I am wrong), it looks like that work does not necessarily need the latest fv3 components.

Would you expand a little bit about this part?

Also, once MPAS-JEDI workflow is build up, we have to do a validation work on with FV3 and GSI

I don't fully understand this. In a cycling mpas+jedi workflow, why do we want to validate FV3 with GSI?

[ShunLiu-NOAA]

Since there is no MPAS interface in GSI, it is hard to compare MPAS-JEDI analysis with GSI analysis. To validate the functions used in JEDI, we have to compare FV3-JEDI analysis result with GSI analysis. In this way, we can find whether some important features developed in GSI are properly transitioned to JEDI. For example, we don't know if we are using the same/similar QC filters in MPAS-JEDI as these in GSI.

[guoqing-noaa]

Since there is no MPAS interface in GSI, it is hard to compare MPAS-JEDI analysis with GSI analysis. To validate the functions used in JEDI, we have to compare FV3-JEDI analysis result with GSI analysis. In this way, we can find whether some important features developed in GSI are properly transitioned to JEDI. For example, we don't know if we are using the same/similar QC filters in MPAS-JEDI as these in GSI.

Thank you, @ShunLiu-NOAA!