QF-Error-Tracking / QFVD5

0 stars 0 forks source link

Upgrade to v5.0.0 #1

Closed iperezx closed 1 year ago

iperezx commented 1 year ago

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.

zacharycope0 commented 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.

zacharycope0 commented 1 year ago

@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.

drosales95 commented 1 year ago

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.

ML_02.zip

iperezx commented 1 year ago

@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.

zacharycope0 commented 1 year ago

@iperezx I wasn't sure what Daniel gave you. I just uploaded the input deck from the samples/LineFire folder .

iperezx commented 1 year ago

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

drosales95 commented 1 year ago

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.

iperezx commented 1 year ago

@zacharycope0 What am I supposed to rename this one: FileNotFoundError: [Errno 2] No such file or directory: 'Output/z_qu.bin'

iperezx commented 1 year ago

@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 ).

drosales95 commented 1 year ago

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).

iperezx commented 1 year ago

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.

iperezx commented 1 year ago

@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.

drosales95 commented 1 year ago

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?

iperezx commented 1 year ago

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?

iperezx commented 1 year ago

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?

zacharycope0 commented 1 year ago

@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.

iperezx commented 1 year ago

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.

zacharycope0 commented 1 year ago

@iperezx image

iperezx commented 1 year ago

you were left out of the party. Just added you. Try again.

zacharycope0 commented 1 year ago

I'm closing issues that I believe to be resolved. Please reopen if you still need something addressed.