You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This might also be an issue for the openfast repo, but the problem appears in when running amr-wind with openfast. When an openfast ALM case is restarted, and you want to extend the length of the openfast simulation by increasing openfast_stop_time, it does not actually change the stop time value in the openfast run.
Note that exceeding the openfast_stop_time value does not actually halt the amr-wind run, but it does prevent openfast from outputting any additional data in the output file or writing out any more checkpoint files.
What I think is happening is that the openfast_stop_time is written into the chkp files, so any new value of stop time needs to be read in after the chkp file is loaded.
Steps to reproduce
A reproducible scenario would look like this. The first run would use these values for the Actuator settings:
This should be sufficient for any runtime up to 1,000 seconds (in our case, the initial run is only 900 seconds). When we want to restart the run, we add these parameters:
If this is a segfault, a stack trace from a debug build (paste or attach):
<!-- stack trace -->
Expected behavior
I'm thinking the solution to this problem will likely involve some combination of calling FAST_OpFM_Init to create a new openfast turbine with the updated stop_time (so the storage arrays get set to the right length), loading in the new checkpoint data, copying it over to the larger arrays, and then proceeding with the run.
AMR-Wind information
==============================================================================
AMR-Wind (https://github.com/exawind/amr-wind)
AMR-Wind version :: v2.0.0-4-gc70c279e
AMR-Wind Git SHA :: c70c279eb6901edc4466d6f96f10e522ca6b62f9
AMReX version :: 24.03-36-g748f8dfea597
Exec. time :: Thu Aug 8 21:46:47 2024
Build time :: May 20 2024 00:00:24
C++ compiler :: Clang 15.0.0
MPI :: ON (Num. ranks = 1600)
GPU :: ON (Backend: HIP)
OpenMP :: OFF
Enabled third-party libraries:
NetCDF 4.7.4
HYPRE 2.31.0
OpenFAST
Additional context
Note that this currently means that openfast_stop_time needs to be set to a very large value which encompasses any possible run duration that might be expected in the simulation. The trade-off, of course, is that the chkp files will get very large in order to store all of the necessary arrays.
The text was updated successfully, but these errors were encountered:
Interesting issue... The proposed fix sounds kinda gnarly. Is there a way to talk to openfast devs to see if there's an easy way to automate this copying of arrays and things? This feels like a limitation of openfast and not amr-wind. Though the fix you describe sounds like more of a workaround to get openfast to do what you want?
Bug description
This might also be an issue for the openfast repo, but the problem appears in when running amr-wind with openfast. When an openfast ALM case is restarted, and you want to extend the length of the openfast simulation by increasing
openfast_stop_time
, it does not actually change the stop time value in the openfast run.Note that exceeding the
openfast_stop_time
value does not actually halt the amr-wind run, but it does prevent openfast from outputting any additional data in the output file or writing out any more checkpoint files.What I think is happening is that the
openfast_stop_time
is written into the chkp files, so any new value of stop time needs to be read in after the chkp file is loaded.Steps to reproduce
A reproducible scenario would look like this. The first run would use these values for the Actuator settings:
This should be sufficient for any runtime up to 1,000 seconds (in our case, the initial run is only 900 seconds). When we want to restart the run, we add these parameters:
Steps to reproduce the behavior:
This is not an error per se, but you can see when the limit of the openfast output file has been reached:
Expected behavior
I'm thinking the solution to this problem will likely involve some combination of calling
FAST_OpFM_Init
to create a new openfast turbine with the updated stop_time (so the storage arrays get set to the right length), loading in the new checkpoint data, copying it over to the larger arrays, and then proceeding with the run.AMR-Wind information
Additional context
Note that this currently means that
openfast_stop_time
needs to be set to a very large value which encompasses any possible run duration that might be expected in the simulation. The trade-off, of course, is that the chkp files will get very large in order to store all of the necessary arrays.The text was updated successfully, but these errors were encountered: