Rapid Accelerator Mode

[umer_khan]

We have a need for running this model in Rapid Accelerator mode in 2012a, but were unable to do so. Does anyone have a solution for this issue.

Thanks in advance,

Umer

[grc.rhc.dev]

Umer, 

Thanks for posting. 

What is the error message you are getting? Are you having issues running all the blocks or just a subset?

Attached below is the response I sent out previously for completeness.

We are aware of the problem.  When T-MATS was initially created it was not built to generate code from.  There is current effort to make the modification necessary to use the Simulink Coder. In early troubleshooting it was discovered there were issues using M-S-functions, so they will be removed and replaced with a more C-friendly arrangement.  This may also correct the problems encountered when attempting to run in Rapid accelerator mode (i.e. looking for target language compiler (tlc) files, which don’t exist), as Rapid Accelerator mode is attempting to write code for portions of the Simulink code to get better performance.

This task is of high priority and we are hoping to work it in the next few months. 

-Jeff

[Mike Corbett]

Umer,

The Cantera stuff makes heavy use of MATLAB S-functions rather than C S-functions or MATLAB Functions (a.k.a. Embedded MATLAB). Those items won't compile (i.e. Rapid Accelerator).

Also, older versions of C S-functions had various ssSetOptions items set which were not compatible with code generation. However, I believe that all of that has been cleaned up. I use a locally modified version of T-MATS but it generates code just fine for me in R2013b (I don't use any Cantera stuff and I see no reason it shouldn't work in an earlier release).

As Jeff said, posting some specifics on the errors or an example model that produces the problem (even better) will help get to an answer.

-Mike

[grc.rhc.dev]

I had a bit of time  so I looked a little more in-depth at the problem and managed to get a few of the turbomachinery blocks to compile, however I still get some error for the turbine and compressor . Keep in mind this is kind of a hack.

Steps:

- Move all *.c and *.h files to working directory  (might also work to just put them on the path, but didn't try that), they are in TMATS_Library/MEX/C_code

- In the S-function definition block  fill out the S-function modules to be the external *.c calls  ( so for example in the Nozzle block drill down to the S-function call and update S-function modules to 'pt2sc sp2tc t2hc interp1Ac interp2Ac PcalcStat'

- Re-name all external files to delete the _TMATS,  for example pt2sc_TMATS.c  ->  pt2sc.c

- Go into Configuration Parameters -> Code Generation ->  Custom Code ...   in the top box  click on header file and put the *.h files that are TMATS related,  for example for the nozzle:

"contants_TMATS.h"

"funcs_TMATS.h"

These would be system wide,  so you need all the .h files used for every block.

- Remove the Scalar_To_Workspace subsystem inside any block where it exists ( as mentioned in my other post),  Also remove anything under the Mask Initialization tab (this may not be necessary, but might as well).

I tested the duct (which has no S-function), Ambient, and Nozzle blocks and these steps worked.  However when trying to do it with the turbine and the compressor I got the error: "Error occurred while executing External Mode MEX-file 'ext_comm':

ExtTargetPktPending() call failed while checking  for target pkt".    A quick Google search on it, suggests it has something to do with communication with my serial ports, which seems a little strange.

-Jeff

[grc.rhc.dev]

Looks like the ExtTargetPktPending() error was due to a command in the compressor and turbine source code.  Fix is to remove: "ssGetCurrentInputPortDimensions" from compressor_TMATS.c and turbine_TMATS.c .   If you know your application you can just hard code this vector length (it is being used for number of bleeds),  if you want it to be more general, input the vector length via a new parameter or S-function input. 

Hopefully that will get you moving in the right direction.  Let me know if you have any issues. 

-Jeff

[umer_khan]

Jeff, Mike,

Thanks you very much for the help, it was much appreciated. Sorry for the late reply, been very busy.

I was working with the JT9D_Dynamic model in 2012a, so my approach in resolving this issue involved running the whole model. It was just a matter of working through the errors. I wanted to share my experience in resolving this issue, which was pretty much a hack, similar to the one Jeff described:

1. As you mentioned, I deleted the Scalar_To_Workspace subsystem inside the block, as prompted by the initial errors.

2. Group the *.mex32 and *.c files into one folder. I copied the *.c files one level up to \TMATS_Library\MEX.

3. The next issue was the redundancy and external referencing of constants and functions in the Nozzle_TMATS.c, Compressor_TMATS.c, Turbine_TMATS.c. I copied these functions into the main source file, at the end.

Compressor_TMATS.c: added interp1Ac, interp2Ac, t2hc, sp2tc

Nozzle_TMATS.c: added pt2sc, PcalcStat

I included the constants_TMATS.h in Compressor_TMATS.c only, and removed it from the other source *.c files. This also required the definition of of the constants used in the other component source files, i.e adding "double C_GRAVITY, JOULES_CONST, C_PSItoPSF" to Nozzle_TMATS.c

4. All of these mods should result in the the error/solution described in the previous post. I did not have to remove anything in the mask initialization.

5. Model should now compile

Another note it is not enough to have TMATS_Library\MEX in the path, this needs to be the current working folder to compile.

Hope this helps,

Umer

[grc.rhc.dev]

Finished making modification for Code Gen and updates are in the current development version and will be release in the next version release.  In general it seems to work. 

The mods are for MATLAB v 2015a and compiler SDK 7.1.  I am not totally sure if its the MATLAB version or the compiler, but a few of the items listed in previous posts were not implemented because they were unnecessary. I am having some issues using the new dataoutput block when T-MATS blocks are in a model call, but this seems fairly minor, hope to have a fix for the next release. 

Changes included: 

1) placing all c and mex files in the same folder on the MATLAB path. (It was not required to place all .c and .mex files with the item to be compiled, they were just required to be on the MATLAB path)

2) re-writing the dataoutput block to use a MATLAB function block with code compiling functions, such as fopen, fprintf.  This led to the creation of binary files for each block when using iDes. Also, the initialization when reading these files was updated and all naming commands beyond the file name were removed.

3) removed abs_D from all code files, there were issues with defining it in too many files. ( I had no issues with constant.h)

4) removed other commands from the C-code that were not compatible with code gen.

5) added the externals, such as sp2tc_TMATS, to the S-function modules  in the S-function call blocks.

For a complete list please view the individual commits.

3b4b84dd58e4af2b5013cf6c1de3f97cc0f9b4aa : Moved C to same folder as mex

11910fbc8e7e605f8be533c9ec95b2520270270a : Code Gen Block updates

24cc0b47513412d7c195e784e17e70960751720d : Code Gen example updates

Cheers,

-Jeff