pnwairfire / bluesky

BlueSky Framework rearchitected as a pipeable collection of standalone modules.
GNU General Public License v3.0
19 stars 11 forks source link

Using custom fuel load #292

Closed chfite closed 2 months ago

chfite commented 2 months ago

I am still fairly new to using Bluesky, so please forgive my lack of knowledge. I figure this is the place to ask for assistance with modeling issues, but if not, please let me know.

I am trying to run Bluesky v4.3.65 for a specific fire point, and I want to use my own fuel load value (example: 13 tons/acre), but am not seeing any difference in my PM2.5 emissions estimates when I modify my fires.json to have have ['fires'] > ['activity'] > ['active_areas'] > ['specified_points'] | 'perimeter' > 'input_est_fuelload_tpa'set to my specific desired value, and I made sure to also set 'config' > 'consumption' > 'scale_with_estimated_fuelload' to True in my conf.json file. It was my understanding that by modifying those two fields, then as it models the consumption process it would use the original fuel load and scale consumption based on my fuel load value? Below is my attached consumption.json file output after running through the consumption module. Are there any issues with my configuration that would cause it to ignore my desired fuel load information? Do you have advice on best practice for this going forward?

Addtionally, I have tried updating other parameters such as as fuel moisture in ['fires'] > ['activity'] > ['active_areas'] > ['specified_points'] | 'perimeter' > 'fuel_moisture_10hr_pct to different values but also do not see any changes in the modeled fuel consumption or my final PM2.5 emissions estimates after it has been run through all modules, so I suspect the issue has to do with my configuration, and not related to the model itself?

consumption.json

jdubowy commented 2 months ago

Support for adjusting modeled fuel load and consumption data based on estimated fuel load was introduced in v4.3.75. So, you'll need to upgrade to a newer version of bluesky. We published v4.6.0 yesterday.

chfite commented 1 month ago

Hi @jdubowy, thanks for your reply. I have updated to BlueSky v4.6.0. Now, when I modify input_est_fuelload_tpa I do see differences in resulting consumption and emissions, which is good. However, I wanted to verify the units for this. Based on the documentation I know this input value is supposed to be in US tons/acre.

In a 204 acre fire case I am looking at the consumption.json file under default settings (when I do not specify my own custom fuel load), it indicates a value for fuel loading total: 4713 and total_available_fuel_loading: 2340, and the resulting total consumption is 1608. First, is it correct that these outputs in consumption.json are in US tons/acre or are they just US tons for all these variables?

I tried setting input_est_fuelload_tpa: 8000 for simple testing , which after running through BlueSky produces consumption.json result of fuel loading total: 8000 and total_available_fuel_loading: 3972, with resulting consumption being 2730. The scale factor it uses is 1.697.

So it sounds like my input variable of 8000 gets used for the "total" fuel loading, and then it determines how much of that is available from there for consumption process.

I actually have field observations from this fire, and samples estimate 400.4 tons total fuel loading for the 204 acre region, which would be 1.96 tons/acre. This means that if I were to implement this and set input_est_fuelload_tpa: 1.96 I would have extremely lower fuel consumption and emissions than what BlueSky determines for this region by default. While I know the model defaults will never exactly match observations, I wasn't expecting it to be this far off. If the variable input_est_fuelload_tpa, the output fuel loading variables total and total_available_fuel_loading, and the consumption summary variable of total are all meant to actually be in tons, not tons/acre, then my field estimate of 400.4 total tons fuel loading wouldn't seem as far off from the default 4713.

Perhaps the code is correct, but I just wanted to make sure of what units all these input and output variables should be and that I'm not misunderstanding something.

Attached are my consumption.json files for the default case and the case where I set the input to 8000 for simple testing.

consumption_default.json consumption_input8000.json

chfite commented 1 month ago

Also, I notice that my heat output does not change regardless of which fuel load I choose. Is there a physical reason why this would be, or should it scale in the code with the same scale factor that is applied to the fuel load?

jdubowy commented 1 month ago

To answer your first question:

First, is it correct that these outputs in consumption.json are in US tons/acre or are they just US tons for all these variables?

Yes, the consumption (and emissions) output are in US tons (https://github.com/pnwairfire/bluesky/blob/master/docs/data-units.md). The fuel loadings in the output are also in US tons. When you specify fuel loadings in the configuration, however, they are in tons/per acre.

You've found two bugs: 1) the heat should be scaled along with consumption and fuel loadings, and 2) input_est_fuelload_tpa is effectively being treated as if it were total estimated fuel loadings instead of per-acre loadings. (The code was assuming that the fuel loadings in the output are per acre values instead of total.)

I'll fix these issues. Thanks for finding them!

jdubowy commented 1 month ago

I published v4.6.6, which contains the fixes.

chfite commented 1 month ago

Ah, great to know! Glad I was able to discover those issues.

If this is the place to ask, do you have any advice on using custom fuel moisture values for a fire? I see for the input data you can put ['fires'] > ['activity'] > ['active_areas'] > ['specified_points'] | 'perimeter' > 'fuel_moisture_10hr_pct', which I assume is the value I would need to modify? I had tried changing the value for this but saw no change in resulting consumption/emissions. And is it correct, that if I am am using custom fuel moisture, I would not need to pipe through the fuelmoisture module?

In the consumption.json files I had posted above, the output under ['fires'] > ['activity'] > ['active_areas'] > has fuel moisture blank as "fuelmoisture": {}, but it had been piped through the fuelmoisture module.

jlbeidler commented 1 month ago

Ah, great to know! Glad I was able to discover those issues.

If this is the place to ask, do you have any advice on using custom fuel moisture values for a fire? I see for the input data you can put ['fires'] > ['activity'] > ['active_areas'] > ['specified_points'] | 'perimeter' > 'fuel_moisture_10hr_pct', which I assume is the value I would need to modify? I had tried changing the value for this but saw no change in resulting consumption/emissions. And is it correct, that if I am am using custom fuel moisture, I would not need to pipe through the fuelmoisture module?

In the consumption.json files I had posted above, the output under ['fires'] > ['activity'] > ['active_areas'] > has fuel moisture blank as "fuelmoisture": {}, but it had been piped through the fuelmoisture module.

Verify which calculations you are using in CONSUME. 10-hr FM is only applicable in activity type consumption equations.

jdubowy commented 4 weeks ago

As James pointed out, 10-hr FM only comes into play for activity type fuels. The example you provided has natural fuels.

And is it correct, that if I am am using custom fuel moisture, I would not need to pipe through the fuelmoisture module?

In general, if you have the appropriate FM values needed by consumption in the input data, then you can skip running the fuelmoisture module. (You can actually skip the fuelmoisture module even if you don't have FM values in the input, since CONSUME has defaults that it falls back on.)

As for why the fuelmoisture module has blank output in your run, it's because the one FM model currently implemented in bluesky (NFDRS) relies on localmet data. Without it, NFDRS effectively does nothing. I'll talk to the scientist who wrote that module. We should probably at least add a warning message indicating the lack of expected localmet data.