Can't export quicfire files if I use landfire to build surface grid

[MaryKBrady]

I get a TimeoutError when I try to run export = Grids.from_domain_id(domain.id).create_export("QUIC-Fire") if I used .with_fuel_load_from_landfire() when building my surface grid. I get no error from the grid building itself, just when I try to export. I do not get the timeout error if I create my surface grid with uniform values. I have tried variations on my export line (export = my_grids.from_domain_id(domain.id).create_export("QUIC-Fire") and export = my_grids.create_export("QUIC-Fire") ) with the same results - works for uniform, not for landfire. It could absolutely be an error in my surface grid building code, but those lines throw no errors or warnings. I copied it below just in case it helps clarify what I'm talking about. Any advice or things to try would be much appreciated!

surface_grid = (SurfaceGridBuilder(domain.id)
.with_fuel_load_from_landfire(
product="FBFM40",
version="2022"
)
.with_uniform_fuel_moisture(
surf_moist #float: 3.0
)
.build())

[amarcozzi]

Hi @MaryKBrady can you please share the geoJSON that produces this error?

[MaryKBrady]

It is currently a geojson file which cannot be uploaded here. Do you have a preferred file type I could convert it to? I might also be able to upload it if I zip the file or I can copy/paste the file contents, it's only a few lines.

[MaryKBrady]

Here it is as a zip. Let me know if you'd like it in a different format
SQM1_E_domain.zip

[amarcozzi]

Thanks, if you ever need to you can copy/paste the contents of a geojson since it's just a plain text file.

[amarcozzi]

@MaryKBrady Thanks. I have some time scheduled this morning to look at this.

[amarcozzi]

@MaryKBrady okay the problem is reproduced on my end. It only happens when you just have a surface grid as a part of your Grids resource. It works fine if you have a tree grid and a surface grid and export the Grids object to a QUIC-Fire export.

That makes me think there is something going wrong in the export code where we handle array dimensionality. We do something funky where if you give us just the surface grid, we'll write that to a QUIC-Fire dat file with nz=1. Something is likely breaking there and I don't recall if we have a test that covers that case. I have to break on this to go to meetings for the day, but I'll come back to this later today or tomorrow.

[MaryKBrady]

Thanks for looking into this! However, the problem occurs for me even when I have a tree grid. I have tested it with both default fast fuels trees and with uploading a custom treelist - for me it is the same error in either case. I will be out of the office tomorrow but will be free to chat next week if you would like

[amarcozzi]

Yeah the problem actually is related to not having the groups field populated. The good news is that if you add:

groups: ["oneHour"]

that will fix your problem.

I'm debating how to handle this at large. I'm leaning towards making groups mandatory and then checking for the oneHour group when you export to QUIC-Fire. How are we supposed to decipher the fuelLoad quantity when we export to QUIC-Fire otherwise?

It also reveals something that I increasingly dislike about how we designed the API: it's opaque how we convert data in the surface grid to QUIC-Fire input files. This will only get worse as we add more data sources and need to be responsible for more of these conversions.

I think users should have the freedom to say "this is my fuel grid that contains components x, y, z that I want to input into QUIC-Fire through my dat files". Currently, we as FastFuels say there is one way and one way only to go from FBFM40, or FCCS, or RPMS to QUIC-Fire dat files and I think that's not a good way to look at it. What if instead when you create your QUIC-Fire export you give it a an explicit surface grid, tree grid, etc. So you could say here is my surface grid with the one hour fuel load and 50% of the ten hour fuel load from the Landfire FBFM40 product, please give me QUIC-Fire dat files for that.

I'm thinking about changing how we handle grids and exports, and I'm debating if we make that change now or push forward and start work on a v2.

Flagging @LeticiaLee and @crawld because we've had related discussions and I think we should take time at the next FastFuels meeting to go over this with your feedback.

[MaryKBrady]

That did the trick! And thank you for including so much context information, that was really helpful

In relation to some of your comments, for the projects that I'm working on, it would be nice if down the road we had that kind of control that you're talking about over which segments of the fuel load go into the dat files. I hadn't even considered it as a possibility before