unifiedgridfile branch dev question

[jlc248]

Hi @deeplycloudy , I've been using the unifiedgridfile branch, since I (naively) assumed this would be merged into master. I was just wondering what the plan is for development on this branch. Should I go back to using master and the separate output files?

As a corollary issue, do you have plans to add the minimum flash area field to unifiedgridfile?

[deeplycloudy]

@jlc248 I need to keep unifiedgridfile separate from master until the operational NWS version can be moved to the new file format. I don't know if/when this will happen, as they'd have to rewrite some things downstream from glmtools. So for now, the new file format lives on unified grid file, and other changes you see happening on master should get pulled into unifiedgridfile.

More generally, the branches have evolved recently. Right now, here's how I envision the purpose of the branches.

• isatss: the 'operations' branch, using the old file format, and receiving hotfixes for various problems, but otherwise slowly changing.
• master: upstream from isatss, so will get hot fixes identified from operations, as well as prototype features back ported to the old file format from unifiedgridfile.
• unifiedgridfile: new file format, supports community products (Unidata feed), and will pull in fixes from master or new features identified/implemented for ops.

Does that make sense? Does it fit your needs? Comments/adjustments welcome.

[deeplycloudy]

And, I should put this in a roadmap document for wider consumption.

[jlc248]

@deeplycloudy , I think this will work fine for me. I'll stick with unifiedgridfile. Thanks!

[deeplycloudy]

It's time for a roadmap status update. Tagging @djhoese, @hopesea79, and @Temurin as other interested contributors affected by branch changes.

• All recent active development is on ugf-newgrid, which is branched from unifiedgridfile, which is branched from master.
• glmtools/isatss is branched from master, and is the stable production version.

The ugf branches have a new file format that is not compatible with ISatSS, but is the format that Unidata is expecting for the public feed, and is also used by @jlc248 and, I think, @Temurin.

@hopesea79 has a proof of concept integration of ugf-newgrid into the ISatSS operational framework.

I would like to propose the following path forward:

1. Wrap up work on the following issues, merging those changes into ugf-newgrid:

• [x] #26
• [x] #54
• [x] #60
• [x] Maybe #31

2. Merge ugf-newgrid to master.

• [x] Done.

3. Make a new isatss-ugf-newgrid branch from master

• [x] Done.

4. Identify the final set of changes needed to make ugf-newgrid work with ISatSS, updating PR #59 by pushing changes to isatss-ugf-newgrid.

• [ ] Done.

5. When isatss-ugf-newgrid is moved from dev to production, merge isatss-ugf-newgrid into isatss.

• [ ] Done.

This would leave us with a single file format produced by glmtools, a master branch for active development, and a stable isatss branch that would be used in production.

Could those tagged above let me know if any operational details block progress on this plan? I don't don't want to do things to the branches that will cause heartache. I suggest setting a goal to have this wrapped up by the end of March.

[jlc248]

I think this plan and timeline sound good, @deeplycloudy .

[Temurin]

This sounds good to me too, thank you. We are not actually using the new file format quite yet (we are still on an old branch), but we will switch to ugf-newgrid in the very near future.

[deeplycloudy]

See #63 for a draft fix for #26 and #54 above. Note that it will change the meaning of -o in make_glm_grids.py, to allow for greater customization of paths and even filenames, so @jlc248 @Temurin you'll need to tweak any of your scripts that call it. @hopesea79 this change will also impact ISatSS integration.

[deeplycloudy]

Testing reported in #31 shows that ugf-newgrid fixes the proj4 bug, so I'm going to check off #31 as fixed in the checklist above.

[deeplycloudy]

As far as I'm concerned, we're ready to merge ugf-newgrid to master (2. and 3.) and transition the focus to isatss in 4. I've opened #64 for the merge in 2. I'd like to merge that next week, so last chance for comment before the big change to master.

[deeplycloudy]

Having merged #64, master is now the active development branch 🎉 and isatss-ugf-newgrid has been branched from master for use in addressing #59.

[jlc248]

Fantastic! I will check this out and test it when I get a chance. Thanks for your work on this!

On Fri, Feb 28, 2020 at 10:17 AM Eric Bruning [email protected] wrote:

Having merged #64 https://github.com/deeplycloudy/glmtools/pull/64, master is now the active development branch 🎉 and isatss-ugf-newgrid has been branched from master for use in addressing #59 https://github.com/deeplycloudy/glmtools/pull/59.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/deeplycloudy/glmtools/issues/30?email_source=notifications&email_token=AEYNAYQQFDIC46K4PDZLBMTRFE2LDA5CNFSM4HM26KFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENJCF2A#issuecomment-592585448, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEYNAYQN5KBYIPNMLGGD5RDRFE2LDANCNFSM4HM26KFA .

[jlc248]

I've tested this out and everything looks great. One question...is there a reason minimum_flash_area is a float rather than a short, like its cousin average_flash_area? I assume the nearest km^2 for flash areas is probably good enough, but perhaps that may not be the case with minimum_flash_area?

[deeplycloudy]

@jlc248 no reason, other than I probably forgot to do it the same way. I documented your good idea in #69, along with a another problem related to nature exceeding what we thought was the largest possible flash area.