Run IEA-15MW Power Curve

[pscrozi]

They were running fine, but after 5500 timesteps (7 revolutions), they failed with negative volumes. Model continues to be somewhat touchy.

Still finding bugs in input files.

Nate: going through automation script and making sure everything is consistent for every wind speed. Lots of search and replace. Lining up timesteps and RPMs.

Derek said we were set up with OpenFAST model, but not even smaller timesteps. So we came up with a function of RPM for very small timesteps for BeamDyn, and backed out other parameters from there. There are little things we need to do before submitting the whole powercurve at once. Comes down to running with a smaller timestep, and lowering the beam order. Still working to make sure the parameters are all internally consistent.

Phil turned on the negative Jacobian check. Potential action item: when there's a negative volume, dump the files to see where the negative volumes are.

Neil has a couple of them running.

[pscrozi]

Nate: got the full set of wind speeds run with BeamDyn only, with no crashes. Should run to about the 80 s mark to make sure things are steady state. Phil and Neil have also been working on this. 10.5 and 14 runs have been run from these results. Question for Ganesh about restarting using a netcdf file, to address in PL. Will need to run these much longer (80 s).

Neil: figured out that the rotor has been rotating around the wrong axis. The tilt needs to happen in a different location (top of tower) at the correct axis, then everything seems to be lining up. The tower and rotor were not in the OpenFAST correct locations relative to each other in the old setup. Now it all lines up. This might have been the cause of the negative volumes.

[pscrozi]

Nate: yesterday launched 3 jobs using precursor data. HPC people offered to allow us to run on Amber with no queues. Jobs immediately began. We were at 1200 timesteps as of last night after about 4 hours. 8 m/s is at 4400 steps. Haven't looked at OpenFast results yet, but Nate will check and will plot the power to see if we're holding steady. Should check the last line in the output file with "less" command.

Neil: runs from yesterday on chama died because chama went down. Moved to Eagle, and updated repo and have a backup set of runs going on Eagle.

Phil: should verify that we're starting with FSI loads fully on. No aerodyn - Nalu load blending going on. We shouldn't have the power going to zero with slow ramp up, but it might be ok. We should examine the results to see if they are acceptable: do we recover the right power from CFD loads. We need to get to the correct steady state, regardless of the path we use to get there.

[psakievich]

Weird output issues due to a raw float to integer conversion fix is here: https://github.com/gantech/OpenFAST/pull/27/files

We have 6 power curve points running on amber with the x86_64 build, but we are having issues with architecture specific build.

6 cases are 1500-1700 timesteps in after 8 hours of running ( 1 revolution)

We won't make it to 10 revolutions before friday, maybe 5-7 depending on the wind speed but we will have full fsi loads.

We are waiting to see if the load blending happens without it failing and we will know today about that.

[pscrozi]

Bad news: they got past the switch to FSI loads, but everything eventually blew up (residuals). Something with the solves went off the rails. Need to time to do post-mortem. Couldn't tell why. Need to add more instrumentation. We've collected more output due to sideset writer. Kudos to those who wrote the sideset writer output.

[gantech]

Instability is only at the higher wind speeds. Power curve is good to go up to the rated wind speed.

[kevmoor]

(Deflection instability) OpenFAST hasn't been run alone for long time (600s) with beamdyn, but confident it can do that. Would be a good test to do. Might be good to also do with the latest dev branch that has the latest beamdyn fixes. Nate coordinate with Phil on doing this a getting a build that everyone can use. Timestep is 1/4 degree for CFD, and 1/100th of that for openfast, have tried reducing both by 2x, but no consistent results due to below instability. Neil will try new GCC build and report.

(Build solver instability) Instability has also been seen in low speed cases, but may be MPI or build related (nondeterministic). May be Sandia specific issue due to MPI bug/options being propagated through the defaults. Should run with latest GCC and will rebuild intel soon.

[psakievich]

Neil started running with the updated beamdyn case from a new build on amber. Cases are blowing up. The team is going to double check against Derek's updated input files and Nate will be rerunning.

Ganesh is running the openfast only case through the cpp interface and is seeing the trouble with the rated wind speed running. Ringing is also occurring and is evident in the tip deflection plots (x-direction, flapping noise). Need to double check results agains the standard openfast interface.

[psakievich]

@gantech mentioned that the nalu-wind meshes are growing in size and increasing the computational cost of these simulations. Additionally it seems that amr-wind needs at least one more refinement level in the background to adequately capture the turbulence. However, performance (time-per-timestep) and resources (number of nodes) required to support this change are preventing us from immediately pursuing this.

[pscrozi]

Issues in running these simulations on Eagle. Not worried about refinement for right now. We just need the simulations to run. Once confident that it will run, need to run for 4 days.

[pscrozi]

Still trying to figure out if there's an issue with the model or our modeling scheme. Neil and Nate have been talking about this. Hang-up with torsional instability. What is the root cause of this?

Neil ran into issues running on Amber, but is now running.