Hello everyone,
While trying to take mean drift forces into account through the use of a “.8” Wamit-format file (generated from Nemoh outputs), I think I found a mistake in the HydroDyn code.
According to the “WAMIT2.f90” file at line 929, HydroDyn will return a fatal error if our simulation’s WaveDirMax is smaller than the “.8” file’s WaveDir1 upper boundary ; on the contrary, it should abort when WaveDirMax is greater than the upper boundary (same issue with the WaveDir2 upper boundary at line 943).
For example, when I used a “.8” file whose WaveDir(1 and 2) range is [-180°;180°], I coudn’t start a simulation with WaveDir = 0°.
There appears to be the same problem in the Newman approximation, difference-QTF and sum-QTF cases (lines 1443 & 1457, 1935 & 1949, and 2372 & 2386) : in each case, the “<” sign should be replaced with “>”.
With the code as it is, one can only take second order loads into account if WaveDirMax is equal to the second order Wamit file’s WaveDir upper boundaries (although it still won’t work with WaveDir = 180° and my “.8” file because of the “known issue #1”).
Thanks again for all the good work on FAST,
Best regards,
Romain
Dear NREL team,
Still on the subject of using a “.8” Wamit-format file, I have made some changes in the HydroDyn code and recompiled a version of FAST (from v8.15, after v8.16 failed recompiling for some InflowWind-related reason). As explained above, I replaced the “<” signs by “>” : it works just fine, but only when my “.8” file contains a row for each crossed WaveDir1/WaveDir2 values. For example, it won’t work if I only have data for 0°/0° and 10°/10° (on account of my data being “sparse”) ; I need to add data for cross-directions 0°/10° and 10°/0°.
My problem is, I do not have those cross-direction mean drift force values (from Nemoh output, I can only calculate them for a single direction). And to be honest, I don’t really understand the meaning of those values : the drift forces for the case where we have waves from two distinct directions, but at the same period… ? In my case, every simulation uses single direction waves so I don’t need that data. But even if I did, I don’t understand why the code shouldn’t read two different lines of data if there are two wave directions, just like it does when there are two wave periods. If anyone has an explanation, I’d be grateful to have it.
Anyway, I tried yet another compiling of FAST, this time after removing the fatal sparseness error. It works and my simulation results are exactly the same as when I tried getting round the error by completing my “.8” file with zeroes for every missing cross-direction mean drift force value. The results look good to me, but could you please tell me whether I’m making a mistake ? Because if it’s all correct, it’s easier for me and could be for others (since I consider directions from -180° to 180° by 10°-steps and 150 periods, cross-direction data would mean hundreds of thousands more lines in my “.8” file).
Best regards,
Romain
Dear Jason,
I also met the same problem when I considered the second-order wave forces from arbitrary wave headings. As Romain mentioned, would it bring other potential problems if I simply remove the sparse matrix check code (line 1054-1059 for MnDrift; line 1511-1516 for NewmanApp; line 1970-1975 for DiffQTF; 2407-2412 for SumQTF) from the WAMIT2.f90 file in the FAST v8.15 source document? In such way, we don’t need to add millions of cross-direction lines in the “.8” or “.9” or “.12” WAMIT-format file. I have tried and found that it works quite well without any error messages.
Best regards,
Shengtao
Dear Shengtao,
The first problem reported by Romain has been added to the OpenFAST issues in github: github.com/OpenFAST/openfast/issues/9. The second problem reported above is not a bug; the direction pairs must be fully populated (not sparse).
Best regards,
Dear Romain,
Thanks for the summary on the issue. You are correct that the wrong sign was used in the checks for WaveDirMax (this appears to have been a copy / paste error when I was developing the module). This has been corrected in the branch that is under development that will allow flexible floating structures, and will be merged into the main repository with that branch.
As a clarification to Shentao’s question, while technically it would be possible to get the code to run by skipping the sparse matrix checks, the resulting 2nd order forces would be incorrectly calculated. The reason is that the matrix is created as a set of N x M matrices of N and M frequencies. As each frequency set is read from the file, it is placed into the corresponding matrix. Any values not read are considered to be zero. During the calculations, those zeros will change the result. For this reason we do not allow sparse matrices.
Regards,
Andy