Closed iperezx closed 1 year ago
Ismael, I talked with the dev team yesterday and they are still tweaking some of the default variables. I'm going to wait on them before I upload the "standard input files" to this repo. Do you have any of the example input files that Sara gave Daniel and I? I can get them to you so that you can get used to the new format.
@iperezx . I uploaded beta input files to the BETA_INPUT_FILES branch. You should only use these file to get familiar with the new input deck.
Hey Ismael,
In the directory that was uploaded, there are a few templates for homogeneous fuels and flat terrain. I've attached the files I used for Mountain Longleaf tests here as well. All of the outputs that aren't related to the grid or specific wind can be considered defaults.
Please let me know if you have any questions.
@drosales95 @zacharycope0 thanks guys! This is all very helpful. Dan also pointed out to me that there is a directory in the QF called samples
that have various input file decks.
@iperezx I wasn't sure what Daniel gave you. I just uploaded the input deck from the samples/LineFire folder .
I think I managed to migrate to the new input file deck for v5.0.0, but I am getting this error:
Working directory is set to: /quicfire/outputs/10/04/run_1004fa26-0dcd-4430-a9bd-1c6e7cc83249
Operating system UNIX
Allocating 8 threads
WARNING: Wind direction will be corrected with domain UTM location.
Small cell physics turned on
Plume time step [s]: 1.0
Initializing fire variables
Error in opening input file: treesfueldepth.dat
Fatal error, the program will be terminated.
I don't think I know where that file is set in the input files: treesfueldepth.dat
Maybe it is helpful to know that I am using FastFuels.
Here is the input file deck: run_1004fa26-0dcd-4430-a9bd-1c6e7cc83249.zip
Change line 19 to use flag 2 on QUIC_Fire and use flag 4 instead of 5 for specifying the fuels. Flag 5 is broken in this version but should be fixed soon.
@zacharycope0 What am I supposed to rename this one: FileNotFoundError: [Errno 2] No such file or directory: 'Output/z_qu.bin'
@zacharycope0 How about this error for uniform fuels:
Path to custom terrain file does not exist.
I don't think we set a terrain file for uniform fuels (correct me if I am wrong @drosales95 ).
Hey Ismael,
In the new version, the custom flag (5) requires a full path not a relative path. It might be easier to rename the topo.dat file to ftelavation.dat and use the Firetec flag (11).
For Fuel flag 4 (Fastfuels), I left the topo.dat as 'topo_fullpath': 'topo.dat'` and it doesnt crashes and completes the simulation just fine (with the errors we are talking about in the PR).
For the uniform fuels I am using the flag 1 but that one doesn't need a topo.dat, right? So I think thats why I get this error from QF Path to custom terrain file does not exist.
@zacharycope0 What am I supposed to rename this one:
FileNotFoundError: [Errno 2] No such file or directory: 'Output/z_qu.bin'
We fixed it by changing it to grid.bin
. I am referencing the new version of drawfire.py
(was not aware of this script) to see what other changes we need to make.
For Fuel flag 4 (Fastfuels), I left the topo.dat as 'topo_fullpath': 'topo.dat'` and it doesnt crashes and completes the simulation just fine (with the errors we are talking about in the PR).
For the uniform fuels I am using the flag 1 but that one doesn't need a topo.dat, right? So I think thats why I get this error from QF
Path to custom terrain file does not exist.
I'm a little confused by some of this. If you're using fuel flag 4 and topo flag 5, then yes: "topo_fullpath': 'topo.dat'` makes sense that it would work. You can also alternatively use topo flag 11 and rename it to ftelevation.dat
If you're using fuel flag 1, then you still have to define a topo flag. If it's set to 5 then it would require the same requirements as above, but if you want flat you can set the topo flag to 0. Is it behaving differently than this?
the confusion feeling is mutual haha
Maybe it will help to give you context of how we deal with upgrades in burnpro3d.
We have a way to test for new changes in burnpro3d (traditional software development). So, every MR on gitlab.nrp we make has to pass the unit test suite.
Since we are doing the upgrade of QF, I catch all the new changes that were introduce from different versions (i.e. v4.0.1 -> v5.0.0) and possibly new bugs that we were probably not caught with the unit tests.
So QF v4.0.1 was working with what is on main of this repo: https://github.com/BurnPro3D/QUIC_Fire.
All the new changes, we are making are here in this PR: https://github.com/BurnPro3D/QUIC_Fire/pull/45 so most of your questions might be answered by looking at what I changed.
Does that make sense now?
One part that came out of the PR is this comment I made about doing the upgrades: https://github.com/BurnPro3D/QUIC_Fire/pull/45#issuecomment-1299404509
Basically why do we have to re-write some of the things that are part of drawfire.py
? Why dont we works towards making it general to target the QF community and stop working in silos?
@iperezx I'm unable to get to your BP3D links. I'm guessing they are private repos?
I agree with your comments about the challenges of integrating new versions of QF. Until recently, the developers at LANL were working on two different branches of QF code. The big changes to the input files and drawfire.py protocol are a result of this recent merge.
You should have access to it. Let me check.
I don't think it is that challenging and that's why I think we can make it into a seamless process (with automation). We just have to make sure the right things are inplace.
Also you get to hear less from me haha.
@iperezx
you were left out of the party. Just added you. Try again.
I'm closing issues that I believe to be resolved. Please reopen if you still need something addressed.
In https://github.com/QF-Error-Tracking/QFVD3.1.1 you guys had a copy of the input files that are supposed to be used for that version. Can they also be available for v5.0.0? I want to make sure the ones we are generating are the same.