FAST Sfunction does not close files

If Simulink initializes the FAST Sfunction but then stops with an error in another simulink block without having started a simulation, the FAST SFunction does not close all opened files. At least the element-File *.elm is still open. If I then want to start the simulation again (when having fixed the problem in the other block), FAST SFunction complains, that the element file is opened by another application and stops with an error.

Is it possible to fix this problem? Thanks! I need to restart matlab each time when there is something wrong in my model.

Best regards
Felix

If I set NOPRINT for all elements, the error remains. Now the .fsm-file is still open.

I have two work-arounds for the problem:

If simulink aborts with an error before the simulation started but FAST’s Sfunc was initialized:
Run “fast_sfunc(0,[],[],9)” on the matlab command prompt to manually close all files

If you forgot to use the command and restart your simulation, FAST will complain about opened files which it cannot access (elm, fsm, out-files). To make it working again you can
a) restart matlab
b) use SysInternals (Microsoft) Process Explorer, and close manually the file handles of the three mentioned files.
No warranty for solution b) …

If you are using Edit->Update Diagramm in your Simulink model, then simulink requests the vector-sizes from FAST Sfunction. At that point the FAST-SFunction opens some files and will not work for the next simulations.

The workarount from my post before will help also in that case.

Hi, Felix.

Glad to see you’ve been figuring out how to get files to close using the FAST S-Function. I thought I would post a little information regarding the structure of this function so that you and others reading this will have a better idea of what is happening.

The S-Function is just a FORTRAN subroutine compiled as a Matlab mex function using the FASTGateway.f90 source file in the FAST archive. The subroutine is called in Matlab using
[y] = FAST_SFunc(t, x, u, FLAG)where y is an output vector, t is the current simulation time, x is a vector containing the states, u is a vector containing the inputs, and FLAG is a flag that determines what the subroutine is supposed to be doing. The following FLAG values are used:

FLAG = 0: This is an intialization step. FAST and AeroDyn (and all the codes linked with them) are initialized, which means input files are read, space for arrays is allocated, and output files are opened. In this case, the return value y is a vector containing the numbers of states (zero*), outputs, and inputs, and a flag that says the function has direct feedthrough. Inputs t, x, and u are ignored. The message, “FAST_SFunc initialized with …” is written to the Matlab command window.

FLAG = 3: This step returns system outputs. The FAST/AeroDyn internal simulation time is set to the input t, and vectors x and u are used to calculate the outputs returned in vector y. Data are written to the output file(s) opened in the initialization step.

FLAG = 9: This is a termination step. It calls the termination routines in FAST and AeroDyn (and codes linked with them) to close files and deallocate memory–basically the inverse of the initialization step. Inputs t, x, and u are ignored and the return value y is empty. The message, “FAST_SFunc completed.” is written to the Matlab command window.

As noted above, memory for the internal FAST_SFunc variables is reserved and files remain opened after the initialization step. If you then clear the S-Function from the Matlab workspace before calling the termination step, the files will be locked and allocated memory will be “leaked” (i.e. unavailable to be freed or used for anything else) until you close Matlab. When we rewrite the code so that there are no implicitly saved variables or states (a big project), we should be able to close files and deallocate memory on initialization, if necessary. That would eliminate the need to manually call the termination step and remove the requirement to clear the S-Function from the Matlab workspace between simulations. However, until that happens, you must make sure the termination step (FAST_SFunc(t,[],[],9)) is called–either automatically in Simulink or manually in the Matlab command window.

*Note that although the function is set up to have zero states, AeroDyn does contain states that the S-Function does not know about. This is a severe limitation, and there will be problems if the function is called without starting at t=0 or if you ever go backwards in time. See this post for more information: [url]http://forums.nrel.gov/t/fast-simulink-interface-and-internal-states/196/1]. We plan to fix this in the future.

I realize this is an old thread, but…

I find that even running FAST_SFunc(0,[],[],9) (which returns “FAST_SFunc completed” ANS = []) Doesn’t release the files, so I have taken to using Process Explorer - handy tip! - but does that indicate something not right in my installation?

Using matlab R2012b (32 bit) and FAST (v7.02.00d-bjj, 20-Feb-2013)-Compiled as S-Function for Simulink.

Thanks,

Monika

Hi Monika,

Usually if files get locked, it’s because I forgot to manually run the terminate call, but there are a few instances when FAST_SFunc 7.02.00d-bjj still doesn’t release files.

Do you always have this problem when you try run the terminate call? or is it just certain files in certain instances?