Error with GFOSUB when using ADAMS with Simulink

Wind & Water Computer-Aided Engineering Software Tools
1

Hi everyone,

I’m trying to run an Adams/Controls simulation from Simulink using a FAST preprocessed data-set. My issue is that, despite my simulation running fine when run through Adams, I get an initialization error when trying to run it from Simulink. Now, I realize this is probably a Simulink or Adams error (and I’m currently trying to contact the Adams people about this), but I think you might be able to shed some light on the problem.

First,I’ll give a short explanation about how Adams/Control works since I know this isn’t currently supported by FAST. Basically after choosing the input and outputs, Adams exports a Simulink s-function block and a controls “.adm” file. The simulation is commenced through Simulink (much like in the FAST-Simulink synchronization), which then opens Adams View shows the progress visually.

In messing around with input data I’ve identified the piece of FAST-written source code that Simulink is not agreeing with: GFOSUB. When I replace all the GFORCE user written functions in the “.adm” file with simple FX=0, FY=0 …etc, the problem goes away. Also, when I run the original file straight through Adams, the problem does not exist. When I try to run the original file through Simulink, Adams View opens, and then immediately closes giving Simulink a very general initialization error.

I’m not much of a programmer but for those that are, does anything come to mind about why Simulink doesn’t like GFOSUB? Other user functions work fine, such as VARSUB and SFOSUB. Also the problem seems to occur in initialization; the model does not get through a single timestep. I know in the A2AD documentation it states that GFOSUB in its first runthrough acts differently than on subsequent runthroughs. Could there be something there?

Any help on this matter would be greatly appreciated.

Thanks,

Jeff

2

Hi, Jeff.

I’m afraid we’re not going to be much help with this topic, but here are my two cents:

The GFOSUB does perform some initializations, particularly, ones for the AeroDyn interface. You might try to run the simulation with CompAero=False and see if that changes anything.

GFOSUB also makes an assumption that the routine is called for blade elements in a certain order; the Adams documentation says you shouldn’t do that, but it has always worked in older versions of Adams. Maybe their interface with Simulink changes that.

One other thought: it might have something to do with the way we write to the screen. You might try compiling with the NWTC Library’s SysIVF_Labview.f90 routines instead of SysIVF.f90. The one for Labview writes everything to a file called CONSOLE.TXT instead of the screen.

Good luck!

3

Hi Bonnie,

Thanks so much for your quick reply. My simulation does run with CompAero=False but if possible I would like to run the simulation with this set to True. I also tried recompiling with the NWTC Library’s SysIVF_Labview.f90. Unfortunately I ran into the same problem. I’m very interested in your second point though…I’m thinking about changing the source code to not assume that the routine is called in order. Have you ever done this? Or do you have any suggestions on how to do it?

Thanks in advance,

Jeff

4

Hi, Jeff.

It looks like I got rid of most of the code that assumes a certain order, with the exception of lin 102 in Adams_Subs.f90. I’d put some print statements in there to see if ( CurrentElement == 1 .AND. CurrentBlade == 1 ) really does mean that it’s the first call to the subroutine for a particular time/DFlag/IFlag combination. That may not be an issue at all. Otherwise, you could add some logical variables to help you determine if it’s been called.

I was also just remembering that we still have some calls to an undocumented Adams INFARY() routine in the AeroDyn initialization routine; we have plans to remove calls to INFARY() because it was removed in later versions of Adams, but we need to make some significant changes to the FAST2ADAMS preprocessor to get it to work. (INFARY() needs to be replaced with SYSARY(), which then needs to be called from a GSE so that it can be called at initialization without setting up system dependencies.)