Dear Jason
I simulated the baseline 5 MW offshore turbine with ITIBarge platform using both ADAMS and FAST, my results from ADAMS and FAST agree well for most parameters. But for “Side-to-side shear force at the top of Tower” I have observed a large discrepancy between ADAMS and FAST results and ADAMS result does not seem reasonable to me.
Have you had same experience?
Regards
Mahdi
Dear Mahdi,
I’m not sure what you mean by a “large discrepancy” (a plot may help), but I have certainly seen differnces between FAST and ADAMS before. These differences are often driven by the higher fidelity modeling of the blades in ADAMS, which include offsets of the blade sectional mass from the pitch axis and torsion DOFs (neither of which are modeled in FAST currently).
Another possibility is that the side-to-side shear forces are most often quite small in value relative to the fore-aft shear forces. When comparing the outputs of different models, variations between models are much more noticable for outputs that are small in value.
I hope that helps.
Best regards,
Hello Jason,
I have been using FAST and ADAMS for a couple of months.
I had initially problems with generating the dll interface between ADAMS 2007 and AeroDyn. With the help of the forum topics I managed to create it (I have no CVF,but Intel Fortran v11).
With the comparisons I got unexpected results. The test 09 available with FAST (UAE VI downwind, in Flexible, yaw ramp, steady wind case), the rotor power obtained in ADAMS is very different (2kW in ADAMS vs 11kW after yaw ramp end in FAST). It seems to be because ADAMS does not get the yaw angle change (although in YawPzn parameter fits between both programs).
I have checked in the manuals and the forum but I do not find the reason.
Could it be because of the dll?(I generated it without errors but I didn’t find anyone else using the same program versions).
I also run other tests but I had no success with ADAMS, I usually get gaussj error (zero pivot ratio). Is it common?
I would appreciate your help.
Regards,
Juan
Hi, Juan.
Jason is on travel so I will attempt to help answer your question.
I suspect the problems you are having with ADAMS result from compiling the dll. I found a compiler compatibility matrix in one of MSC Software’s technical articles ([url]http://simcompanion.mscsoftware.com/infocenter/index?page=content&id=KB8018109[/url]), which indicates that IVF 11.0 is “officially unsupported” for ADAMS 2007 R1 and 2008 R1. I don’t know enough about IVF 11 (I’m currently using v10.1) to know what differences there might be–I do know that ADAMS hard-codes the names of some of the IVF compiler libraries into their software, so it is difficult to use compilers that they don’t specifically support. You might contact MSC Software just to see if they have any ideas, though.
If the code is compiled correctly, the certification tests will not give you gaussj errors. Here is the rotor power for the FAST certification test 09 compared with ADAMS 2005R2 compiled with CVF:
I hope that helps.
Hello Bonnie,
Thank you for your answer.
I am actually working in downgrading my IVF. Altough I though it was easy it mustn’t, I have no administrator privileges and it is taken some time.
Before I didn’t know the issues you mentioned, but now I am very sure that the problem is in the dll.
Thank you again and regards,
Juan Garcia
Hello,
I have installed the new versions of FAST, AeroDyn and AD2AeroDyn.
Although initially it didn’t work, finally I managed to compile the ADAMS.dll file changing the COPTS option in CompileLinkA2AD.bat.
The problem was with the /O1 option. I had to add this option of optimization of the compiler in order to get a dll without errors (the generated errors were referred to trigonometric functions).
It happened to me in both 32 bit and 64 bit computers. I use IVF 11.0
With the mentioned change I got the dll file and FAST & ADAMS results match(checking in some test files some parameters) in the following cases:
32bit computer and Adams 2007r1 and Adams 2010r1 32bit (IVF 11.0 32 bit)
64bit computer and Adams 2008r1 64bit (IVF 11.0 64 bit)
But I had problems with:
64bit computer and Adams 2010r1 64bits (IVF 11.0 64 bit) => It construct the dll without errors but while running ADAMS, the program crashes with the next error:
[size=85][i]’ ---- START: ERROR ----
GFOSUB(11010, 1, 1, 0, 11010) has been illegally defined. A new functional dependency on the measure
TDISP(11010,1,1) has been encountered during execution.
---- END: ERROR ----
'[/i][/size]
I would appreciate if you know about both of these errors in order to avoid them in the future, because I am not used with Fortran compiler and I found it just changing options.
Thank you and regards,
Juan Garcia
Hi, Juan.
It sounds like you’ve found a way to get IVF 11 working with several versions of ADAMS. The ADAMS documentation lists the recommended compiler options, including the level of optimization. It doesn’t include /O1 for 2008r1, but I really couldn’t tell you if that would be an issue anywhere–you’d have to ask MSC about it. If the Adams CertTest (in the FAST CertTest folder) gives you the same results and it runs in a reasonable amount of time, I’d say don’t worry about it.
The error you get with the 64-bit Adams 2010r1 appears to be caused by one of the undocumented Adams subroutines that is called in A2AD (for anyone who cares for these details, we use INFARY() instead of SYSARY() in a few places; we have to restructure the code to get rid of this). In the past, using the undocumented subroutines has been a problem with the C++ version of Adams, but not the Fortran version. We haven’t tried any version of ADAMS 2010 at NREL so I haven’t encountered that issue.
Hello Bonnie.
Thank you for your answer.
I will continue working with ADAMS 2008 for the 64bit computer.
About the run times, I have here some data for the 64bit computer:
Test09 FAST:16.359s; ADAMS: 254.72s; Simulated:40s
Test10 FAST:4.7656s; ADAMS: 21.938s; Simulated:25s
Test11 FAST:4.1406s; ADAMS: 17.422s; Simulated:20s
Test12 FAST:4.0156s; ADAMS: 16.781s; Simulated:20s
Test13 FAST:8.5312s; ADAMS: 31.688s; Simulated:40s
Test14 FAST:2.3281s; ADAMS: 6.7188s; Simulated:10s
Test15 FAST:17.062s; ADAMS: 86.391s; Simulated:20s
Test16 FAST:16.094s; ADAMS: 83.469s; Simulated:20s
Test17 FAST:62.544s; ADAMS: 344.64s; Simulated:70s
I will also ask MSC about the optimization option and I will post here the answer if it could be interesting for anyone else.
Regards,
Juan
For anyone that’s interested, the ADAMS documentation lists the following for FORTRAN compiler options:
/c /architecture:pn4 /MD /Ob2 /automatic /Z7
(Z7 is used for debug mode, and can be removed)
I’ve also run into the same error as Juan:
! ERROR: GFOSUB(11010, 1, 1, 0, 11010) has been illegally defined. A new functional dependency on the measure
! TDISP(11010,1,1) has been encountered during execution.
‘Error calling INFARY for blade element coordinates.’
It should be noted that using INFARY instead of SYSARY is not only causing errors to crop up in different versions of ADAMS (I use MD ADAMS x64), but it will also cause poor convergence rates for the ADAMS solver. Using SYSARY requires declaring a dependency so that ADAMS knows to perturb those markers in the Jacobian. Using INFARY does not. This is really bad news since the forces between blade nodes should definitely depend on the displacement of the markers on either node. I’m actually surprised that the ADAMS simulations converge at all, considering most of the system consists of the blade nodes & connecting force elements. If you have access to the ADAMS user forums, I found info on the topic here, and it’s from an extremely reliable source:
forums.mscsoftware.com/adams/sho … #Post53469
I have a feeling the A2AD simulations would run much faster and crash a lot less if those INFARY calls were replaced with their proper SYSARY counterparts.
Justin
Dear Justin,
Unfortunately, A2AD was originally developed using the undocumented INFFNC() and INFARY() routines instead of the documented SYSFNC() and SYSARY() routines to avoid issues associated with functional dependencies. These undocumented routines are not available in some releases of MSC.ADAMS (e.g., the C++ solver). We know the problem cannot simply be eliminated by switching the INFFNC() and INFARY() calls to SYSFNC() and SYSARY() calls; this would lead to numerous alternative problems.
Instead, NREL is working with MSC to restructure A2AD in such a way as to only use documented routines and to improve the numerics of the solution.
Best regards,
