upstream repo for FV3 dycore development is changing - how best to track this switch

[jtruesdal]

Our current CAM/FV3 port - ESCOMP/FV3_CESM is forked from NOAA-EMC/GFDL_atmos_cubed_sphere which is itself a fork of the official GFDL FV3 source repository NOAA-GFDL/GFDL_atmos_cubed_sphere. I found out that FV3 development switched last week and is now taking place on the dev/emc branch of the official NOAA-GFDL/GFDL_atmos_cubed_sphere repository. I am assuming that we will want to track NOAA-GFDL and am unsure of the future of NOAA-EMC. I think we may be able to transition to using NOAA-GFDL directly in the future but we are not there yet and still need a ESCOMP repository that has CAM-specific modifications for the FV3 port. Should we create a new repo under ESCOMP that is a fork of NOAA-GFDL/GFDL_atmos_cubed_sphere?

[gold2718]

I do not know if we want to follow the dev/emc branch or a GFDL development branch but in either case, a fork sounds like a good idea.

[mvertens]

@jtruesdal - could you please join the CSEG meeting tomorrow 4/13 - so that we can discuss the FMS problem and how to move forwards with the alpha tag.