Simulink modeling: How do I avoid the use of multiple Matlab fcn blocks for discretization?

Dear community,

I have developed a thermal model of a certain pipe system, which contains a thermal fluid and receives solar heat radiation. Thus, the pipes and fluid heat up. It is a state space model in the form of Matlab function blocks, which pass on a number of signals. The model is controlled by a PID controller, more precisely the mass flow of the fluid is controlled to achieve a set temperature at a certain point. However, I feel like the structure of the model is poorly done:

• I am interested in the temperature of fluid and pipe in regular length intervals. For this, I used identical Matlab function blocks connected in a series. They all have the same content and solve the state space model for a certain length interval. This allows me to grab the data for this length interval, but makes changes to the model logic itself a tedious, silly amount of work, where I have to replace every single "discretized" Matlab fcn block with the "new" Matlab fcn block, that contains the changes. Is it possible to make, for example, dependant copies of the 1st Mfcn block that is used? And if I make a change to the first, all the following blocks are changed as well? Or is the use of Matlab fcn blocks not recommended at all in an application like this and there is a better solution?
• The network looks like a a grid. It goes like this: 10 pipe segments - 1 collector segment - 10 pipe segments - 1 collector ... and so on for a total of 80 pipe segments and 7 collector segments. The pipe segments share the same state space model, the collector segments have their own ss model. What would be a good way to distribute an 8x10 signal through the network, so that one value is applied to each pipe segment, without adding 80 ports and signal connections by hand?

I believe the structure can be improved immensely and I would like to learn how to handle a bigger model like this efficiently.

Cheers!

Answer 1

[Felix Schönig]

If someone ever finds this thread and has a similar problem: The solution are libraries, which can act like classes, when you can create instances of the blocks or subsystems in your library. If you change the library block, the linked instances get changed too.