A2AD with MNF files / C++ Solver

Hello everybody,

I am new to this forum, and I would first like to thank you for providing and supporting your wind turbine analysis tools!

I am currently trying to build a model using flexible bodies / mnf files for the blades, which I create using ANSYS. I took your 5MW model, removed all blade-specific lines from the .adm file, and rebuilt the blades with mnf files in Adams/View.

One thing I found from the ADAMS MD R3 help (should be 2008r1) is, that only the C++ Solver of Adams can handle multiple GFORCEs on one flexible body correctly. Using the Fortran Solver always orients all GFORCEs that lie on a common flex-body in parallel direction.

Using the Fortran Solver and my MNF-model, I can run simulations, but they are incorrect, due to the mentioned limitations. However, when I try to run the MNF-model with the C++ Solver and the Aerodyn-Subroutine, I get the following error:

[code]---- START: ERROR ----
GFOSUB(11001, 1, 1, 0, 11001) has been illegally defined. A new functional dependency on the measure
TDISP(11001,1,1) has been encountered during execution.

---- END: ERROR ----
Error calling INFARY for blade element coordinates.

Aborting A2AD.[/code]

in this thread: click me in the third to last and second to last post I could read, that someone else had the same problem, and that it is caused by some calls of the undocumented INFARY instead of SYSARY, that trouble the C++ Solver, but not the Fortran Solver.

So here are my questions:

  • Is it basically possible to use Aerodyn v13.00.00a-bjj with A2AD and the C++ version of the ADAMS solver?
  • Do you have any experience or recommendations for modeling the blades using MNF files / flexible bodies instead of the current way of modeling?

Thank you very much,

Luiz da Rocha

Dear Luiz,

Unfortunately, the ADAMS-to-AeroDyn (A2AD) interface 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. In the standard release of MSC.ADAMS, the INFFNC() and INFARY() routines are only available with the MSC.ADAMS Fortran solver. We know the problem cannot be eliminated simply by switching the INFFNC() and INFARY() calls to SYSFNC() and SYSARY() calls. Instead, this will require a rewrite of the A2AD interface. We plan to do this, but it will not be available in the immediate future.

Until then, my understanding is that MSC has a patch for the INFFNC/INFARY() issue in the MSC.ADAMS C++ solver. They’ve told me that a patch exists and that I could obtain it if I wanted it, but that they would not let me redistribute it. I never asked for it because I have not had the need for it. But, I’ve heard from other users that it works. I suggest you contact MSC and ask about it. If they help you solve the problem, please post a procedure for the benefit of other users following this forum topic.

Best regards,

Dear Jason,

thank you for your reply!I will try to get this patch from MSC.

One more question: Could you tell me, how the list of requestet output variables is defined? As I am using MNF files, your way of determining for example the root bending moment does not work anymore, and thus I get a lot of error messages during the calculation as the corresponding fields do not exist:

[code] ---- ERROR ----
Errors found in call to SYSARY.

---- ERROR ----
VARIABLE Adams.CalcOuts_V has been illegally defined.
A new functional dependency on Function RFORCE has been encountered
during execution.[/code]
I Think these error messages slow the calculation down, so could they be turned off by (for now) not requesting the corresponding output values?

Thanks,
Luiz da Rocha

Dear Luiz,

The VARIABLE/1 (CalcOuts_V) statement calls routine VARSUB() that is used to call routine CalcOuts(), which calculates all of the output parameters. The REQUEST/1 (UserRequest_R) statement then calls routine REQSUB() that is used to call routine WrOutput(), which writes the output data to the output file. Since you’ve removed a lot of statements from the ADAMS dataset, you will need to modify routine CalcOuts() accordingly.

I hope that helps.

Best regards,

Dear Jason,

Thank you very much for your help. The procedure for getting the C+±Solver/INFARY-Patch from MSC was relatively simple:
After the support request, we had to sign a paper, that this patch has not been as rigorously tested as a normal release. Having done that, we got a zip file containing four files, that we could just replace in the Adams installation. From there on Aerodyn worked in the C+±solver.

The errors that I received came from the blade gauges. Having removed them by removing the ARRAY/2 from the adm dataset, the error messages were gone. The remaining output is still calculated perfectly.

Right now, I can say, that my simulations run fine, and the predicted results are very similar to the results from FAST and Adams. The main problem right now is the calculation speed, which is a lot slower than with your current way of modeling the blades in Adams. I have splitted each blade in five MNF files, and enabled only the first bending modes for each flex body.

Best Regards,
Luiz da Rocha

Dear Luiz,

Thanks for the update on your progress. I’m glad to hear that the patch worked.

I’ve heard that the C++ solver of ADAMS is a bit slower than the Fortran solver. As I said in a prior post, we are working on an update to A2AD that will allow it to function in both the C++ and Fortran solvers (with a patch). We should have a better understanding of the speed issue when we get farther along with this update.

Best regards,

Hello again.

I am experiencing a new problem now. When I use the C++ solver (PREFERENCES/SOLVER=CXX in the acf file), Aerodyn does not produce the important output files, like the .plt file and the .dbg file from the controller dll. I do however get the .gra, .msg and .opt file, and the subroutine works, i.e. it produces reasonable forces on the blades (seen from the .gra file).

If I run the same model with the Fortran solver by simply removing the PREFERENCES-line, the output is written nicely.

This is the case with both the original NREL5MW model as well as with my modified MNF model. I Am running the newest FAST, A2AD, AeroDyn, compiled with the Intel Fortran 11.1 compiler, and MD Adams R3 (2008.1) on windows 7 64 bit. I have the same problem on Win XP 32bit.

It is strange, because in contrast to the .gra and .msg files, the .opt file is produced by the subroutine, and this one works with the C++ solver. Any Ideas how this could be quickly fixed?

Thanks,

Luiz da Rocha

Dear Luiz,

It is the REQUEST/1 (UserRequest_R) statement that calls routine REQSUB(), which is used to call routine WrOutput() that writes the output data to the *.plt file. I’m not sure what would cause the problem you are reporting, but this is where I would look for the solution.

Best regards,