Add 1000-hour fuel moisture to FMDA

[janmandel]

On request.

[janmandel]

running in /uufs/chpc.utah.edu/common/home/kochanski-group4/jmandel/wrfxpy_fmda_3 outputs at https://demo.openwfm.org/jm/ branch develop-65

[janmandel]

It seems to be working fine. Remember to delete wksp_fmda/* because the format of state files is different, one more variable is expected. But for proper results we need to a spinup at the scale of 1000s of hours. Increasing the lookback period does not work because lookback is implemented by recursion, which is not efficient and chokes. An alternative is to modify rtma_cycler to run from an arbitrary time #66 and simulate a long history from RTMA cache in ingest/RTMA, We'll see what happens when the cache has gaps...

[adamk0]

Jan, I’m afraid we are just a half way there. The 1000h fuel moisture to me meaningful would need to be assimilated from the national fuel moisture database https://www.wfas.net/index.php/national-fuel-moisture-database-moisture-drought-103 . Without it, it will be more a science fiction than the data assimilation product. Same with 100h FM. There are field data that we would need to assimilate if we want to call it a data assimilation. For now, 10h is an assimilation product 100h and 1000h would be data extrapolation products, and we have no idea if they make any sense. Because anyone can download 1000h fuel moisture from NFMD and verify our estimates, making 1000h as a new product available w/o the actual data assimilation can undermine our credibility.

Thanks, Adam Kochanski

Assistant Professor Department of Meteorology and Climate Science Wildfire Interdisciplinary Research Center San Jose State University

From: Jan Mandel notifications@github.com Reply-To: openwfm/wrfxpy reply@reply.github.com Date: Sunday, September 13, 2020 at 2:12 PM To: openwfm/wrfxpy wrfxpy@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [openwfm/wrfxpy] Add 1000-hour fuel moisture to FMDA (#65)

It seems to be working fine. Remember to delete wksp_fmda/* because the format of state files is different, one more variable is expected. But for proper results we need to a spinup at the scale of 1000s of hours. Increasing the lookback period does not work because lookback is implemented by recursion, which is not efficient and chokes. An alternative is to modify rtma_cycler to run from an arbitrary time #66https://github.com/openwfm/wrfxpy/issues/66 and simulate a long history from RTMA cache in ingest/RTMA, We'll see what happens when the cache has gaps...

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/openwfm/wrfxpy/issues/65#issuecomment-691726072, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA6K3WP7WGWGEYNQ4QCN2ZDSFUYSRANCNFSM4RJBYDTQ.

[janmandel]

Data from NFMD now integrated in the visualization at https://demo.openwfm.org/sj/ Need to integrate into data assimilation

• modify the method from Vejmelka et al 2016
• integrate into the software data flow

[Fergui]

Included in #68