I am making two separate SimBiology Models with the same compartments but different species. Transport between the compartments are different for each species. I want to combine the two models so I can add an interaction term between the two species and use the simulations to get concentration profiles of both the species. Is there a function to do that in SimBiology? I have not been able to find one. If not, what would be the best approach to code a function to do so?
The most relevant function is copyobj. You can also use the SimBiology Desktop's graphical interface to copy and paste one model into another. I also have a prototype of a function for combining two models that I would be happy to share. If you're interested in that, please contact me via my MathWorks community profile.
Your best bet would be to write a script based on copyobj function provided by Matlab, if you want to copy programmatically. You need to be little cautious here as this function throws an error, IF the object copied and the target model have name conflicts. For example, if you want to copy a compartment by name 'C1' from a source model to a target model that already contains a compartment by the same name ('C1'), then the program throws an error due to name conflicts. In such a case you have to programmatically rename the source 'C1' compartment before you copy it to the target model. The rename command provided by Matlab might be useful.
Even after overcoming the errors due to name conflicts, there is another problem with the above method --- the layout/diagram of the models will not be preserved. If you want to preserve the model layout (that is the diagram of the model), you can use GUI based simbiology model builder. First you manually select the model/submodel that you want to copy, click 'Ctrl+C' (like you would do for copying a text) and paste (Ctrl+V) it in your target model. The name conflicts will be automatically handled by the matlab. That is the source 'C1' compartment will be automatically renamed by matlab (to probably 'C2'), and pasted in the target model.
You may look at this function, that probably helps you to build your custom model merger programmatically. It is an old function that works with older versions of Matlab, and may not be relevant now. But it may provide some guidance on building your own script.
Related
I have a very simple question. Normally in other programs, such as word, you can just simply save the document under a different resulting in two separate documents. However, this doesn't work for AnyLogic. Does anyone know how to duplicate a project?
If you do file save as it will create a new alp file for you
But for it to be a truly different model you need to change the Java Package to something unique... See how it is kept as model24 in my screenshot
But be careful it can have some unwanted consequences in a very complex model and you will need to fix these manually, but all doable
My questions is about bringing a concept to reality through technical availability of EA.
I am looking for a way to connect instances at an object diagram through which I can transfer tagged values. Let me explain the background of the project.
Purpose is to first have Stereotypes for specific roles in the system, such as "Calculation", "Transmission", "Decision", "Qualification", "Abstraction" etc.
Each of these stereotypes have specific tagged values suitable for their purpose.
Then I am creating instances from these stereotypes, eg. "MotorTorque:Calculation" and "LimitedTorque:Abstraction"
Each of these instances have a common tagged value, "criticality", boolean and I want this tagged value to progress from "MotorTorque:Calculation" to "LimitedTorque:Abstraction" through an output port > some sort of flow > input port kind of way.
Questions are:
1- Is this approach technically achievable in EA? If so what would be the correct way to do it?
2- The purpose is to have this "connection" readable in XMI export of the diagram which I will be using as an input for another purpose.
I have created an MDG Technology for my project with stereotypes and tagged values, however, I am having difficulty achieving this "connection", this "flow" of values.
Thank you for your time.
What you are asking for is not directly achievable. However, many ways lead to Rome.
One way would be to <<trace>> connect those objects to a Status class (or what ever you like to name it) and have this carry the "shared TV".
Another way is (by far more complex) to use an add-in. You would anyway need ways to create groups which share the TV. From your current explanation I can't see what that might be. Maybe the instantiating class of those instances? If so, you make a script that propagates a TV setting from ist current to all other linked instances. I'm not sure if the add-in events fire when a TV is changes (I do have some doubts here). If needed I could look that up.
What you propose is partially feasible.
There is a tagged value inheritance chain in EA, in which tagged values are inherited down the generalization chain, and from a classifier to its instances. In the GUI, inherited tagged values are shown separately from the instance's own ones, and in the API they are accessed using the Element.TaggedValuesEx property. Inherited tagged values can also be overridden.
Since the correct way to create a port (or part/property) is to make it an instance of a component, a port will inherit any tagged values from that component. So if your Calculation stereotype applies to component, ports which are instances of Calculation components will inherit the MotorTorque tagged value.
However, there is no way to "flow" tagged values from one port to another. If you want such a function, you'll have to implement it yourself with an Add-In.
Regarding XMI, first you must understand that an XMI export is based on a package, not a diagram. The XMI format itself is extensible, which means that different tool vendors create their own extensions which are typically not publicly documented. Crucially, diagram layouts are part of these non-standardized extensions. In EA's case, the image data is some sort of UU-encoded bitmap which you won't be able to extract any useful information from.
Elements' tagged values are included in an XMI export, but again, the EA extensions are not publicly documented. In other words, you can import EA:s XMI format in another program, but you will need to reverse-engineer the format. Not impossible, but it's probably better to either write your own specialized export function, or export via CSV. Note, however, that CSV export cannot be automated -- there's no call for it in the API.
I'm working on an extensive Matlab based GUI that was created with GUIDE. Saving the full state of a GUI seems to be a laborious task as it is generally impossible to efficiently make a self-contained copy of the handles structure. From what I've gathered in my web searches, the current work-around is to manually create a new structure and store the necessary properties of all the uicontrols in the GUI in appropriately named fields. For example if there's a uitable in the GUI, you might want to include in the new structure a field called tabledata where you store the Data from the uitable. The idea is then to save this new structure to a .mat file and load the state of the GUI again by reading this file and doing the inverse exercise of manually copying fields.
I called the above a work-around instead of a solution because it's quite laborious for a large GUI. If anyone has a better/quicker/shorter/cleaner way to do this, please feel free to share! I've come up with a shorter and from some points of view cleaner way myself, but there are a few reasons why I might still prefer the above work-around. In any case my question is about that work-around.
The biggest problem with it is that your saving and loading code must be inclusive: every value and property that can be adjusted by the user should be saved into the newly created structure. For a large GUI it's a real pain, nigh on impossible, to find out which values and properties are adjustable by manually checking everything. Especially with the properties of one uicontrol possibly influencing certain properties of one or more other uicontrols. So my question is: is there a way to get an overview of all the values and properties that a user can influence for a given GUI?
Look into a function called uiinspect coded by Yair Altman. It produces a list of all methods, callbacks, and properties.
A full explanation of how the function work s is located here.
Short version
I am considering to use BusObjects to implement hard interface control on a (large industrial) application using Simulink and I would like to store the BusObjects (hundrends of them) into a Matlab structure so that the entire application interface specification is well organized. However, it seems that BusObjects cant be contained into structures, nor they can reside on other workspaces other than Matlab Base. Any idea on how to handle this?
Long version
I would like the interfaces specification to be hierarchical and centralized in some way. I mean, I would like to specify the external interface of my application, then the internal interfaces, then the internal interfaces of the internal interfaces and so on. And I would like this information to be stored in one object that resembles the hierarchy. I was thinking in using an structure with BusObjects as elements.
Unfortunately, it seems that, for a bus object to work, it must be declared on the Matlab workspace as an independent variable of class BusObject. It cant be an element of an structure that is a BusObject, or an element of a cell whose elements are BusObjects or an element of a BusObject vector.
Any suggestion on how to handle this? take into account that if you have a model with dozens and dozens of blocks and more than 3 hierarchy levels, then you end up with hundreds of bus objects in the Matlab workspace without any particular structure... I think that is too messy to let it be...
Bus objects are always stored in the global workspace.
Send a request to Mathworks if you want to change this.
The user in this webinar;
http://www.mathworks.com.au/videos/parameterizing-bodies-68850.html?form_seq=conf1134
can create new levels of links for the scissor lift by copy pasting the sub systems.
I was wondering if there was any way the number of subsystems and the joints could be automated via user input.
i.e a gui which allows the user to input the number of levels in the scissor lift and that number of levels (subsystems) is generated in SimMechanics.
If someone could provide a solution I could adapt it to the problem I'm trying to solve.
Thanks in advance!
Yes, you can automate it, as long as you know what susbsytems and what joints you want to add. The functions of interest are:
add_block(path_to_your_subsystem,path_to_destination_subsystem) (I assume your susbsystem is stored in a library). You probably want to specify the 'Position` parameter so that all blocks don't end up on top of each other. It will take some experimenting to find coordinates that work for your model and that are parameterised based on the number of susbystems to add.
add_line(path_to_subsystem_of_interest,path_to_output_port,path_to_input_port). You'll need to know which port you want to connect to which and figure out how many times you need to do this based on the number of subsystems to add. Simscape and SimMechanics are a special type of ports, and you need to refer to them correctly otherwise it won't work, see Programatically connect two subsystems for more details (note: this is undocumented as far as I know and is therefore likely to change in a future release).
So in short, yes it's possible (I've done it in the past), but it's by no means easy. See this blog for a very simple introduction.