Advice on using submodels

[Robert Mcanany]

Hi Harry,

I am attempting to model a production line.  The Line consists of 2 Lanes.  Each Lane has 9 Modules.  Each Module has 9 Racks and a Transport.  The Transport has 5 Stations.

Sub-models seem like the perfect way to attack this.  

We are in the design phase, so I won't be able to complete any sub-models ahead of time.  They will all change as we go.

My first thought was to create separate *.sub files and refine them as needed.  However, importing a sub-model seems to be a one-time thing.  When I tried to re-import, I got errors.

I tried a couple of other ways, but finally realized I should just ask the Master.  What is the best approach for this situation?

Robert

[Robert Mcanany]

OK, that's a pretty vague question.  I guess I am looking for the "Best Practices for Sub-Models in JaamSim" whitepaper.  Is there such a thing or something similar?  I read through several forum posts regarding sub-models and got a lot of clues.  Just trying to put it all together in my head.

[Harry King]

Hi Robert,

You are correct that your project will be much easier to build using SubModels. Unfortunately, there is no real documentation on how to use SubModels yet.

When modifying a SubModel, you can either do it in place and re-export and overwrite the .sub file, or you can edit your input file and add an 'Include' command to load the .sub file instead of importing it. The latter method has the advantage that the code for the SubModel is kept separately from the main model file, which makes the model and .sub files easier to understand and maintain. The user manual describes how to use the 'Include' statement.

Note that you should only use clones of the SubModel object in your model logic. The original SubModel object should not be used directly. Just leave it on the sidelines of your model where you can examine it when necessary.

Harry

[Robert Mcanany]

That is very helpful.  Thank you!  

I haven't used your software in several years.  I'm amazed at how you keep finding ways to improve it.  It's awesome!

[Anthony Earl]

You might find that nesting sub3-models will make your model-creation easier and more maintainable if there is a lot of consistency in the copies you describe.

[Robert Mcanany]

I appreciate the feedback.  I'm currently trying to wrap my head around the whole thing.  

For example, I built a Module sub-model containing Rack and Station sub-models as I described in my previous post.  A Rack needs to know when to release something to a Station.  I have an Expression Threshold (ET) at the Module level to control that.  

Since everything is contained within the Module, I thought a clone would know that the ET should refer to the comparable entities in the clone.  Instead it still refers to the prototype sub-model.

I'm not complaining and it's not hard to fix.  I just wish I could get a better handle on the rules.

[Robert Mcanany]

I'm making some headway on this.  My main issue was getting cloned submodels to reference the entities in the clone, rather than pointing back to the prototype.

It seems like clones respect "downhill" references.  For example, the NextComponent in a submodel object can point directly to a nested submodel within.  When the prototype is cloned, it knows to reference the nested submodel of the clone.

The reverse does not appear to be true.  If an entity in a nested submodel points to an entity in the parent, the cloned nested submodel will point back to the prototype.  The recommended way to handle that, as I understand it, it to leave those references blank in the prototype then populate them in the clone.  With many nested submodels and many clones, that's a lot to keep track of.

I got around it by using the syntax "this.Parent.Parent.[<entity_name>]" in the prototype nested submodel.  As far as I can tell, it seems to be working.  It's early days, though.  I'm sure there are more surprises in store for me!

One place I couldn't get it to work was with Thresholds.  Not sure what's going on -- it acts like the error checker, rather than trying to resolve the reference, only checks the literal input list.  The way I got around that was to add a (seemingly redundant) ExpressionThreshold in the nested submodel.  That entity type allows and correctly resolves the "this.Parent.Parent.[]" syntax.

Anyway, here's a picture.  My model is attached.

[Harry King]

Hi Robert,

See my replies in blue below.

I'm making some headway on this.  My main issue was getting cloned submodels to reference the entities in the clone, rather than pointing back to the prototype.

It seems like clones respect "downhill" references.  For example, the NextComponent in a submodel object can point directly to a nested submodel within.  When the prototype is cloned, it knows to reference the nested submodel of the clone.

The reverse does not appear to be true.  If an entity in a nested submodel points to an entity in the parent, the cloned nested submodel will point back to the prototype.  The recommended way to handle that, as I understand it, it to leave those references blank in the prototype then populate them in the clone.  With many nested submodels and many clones, that's a lot to keep track of.

I got around it by using the syntax "this.Parent.Parent.[<entity_name>]" in the prototype nested submodel.  As far as I can tell, it seems to be working.  It's early days, though.  I'm sure there are more surprises in store for me!

HK - Yes, your syntax is correct. However, it is best to avoid external references in a SubModel as much as possible. In the case of your SubModelEnd object, you can leave the NextComponent blank in which case it passes the entity back to its parent SubModel which can then send it to Sub.SubSub1 using its NextComponent input.

 

One place I couldn't get it to work was with Thresholds.  Not sure what's going on -- it acts like the error checker, rather than trying to resolve the reference, only checks the literal input list.  The way I got around that was to add a (seemingly redundant) ExpressionThreshold in the nested submodel.  That entity type allows and correctly resolves the "this.Parent.Parent.[]" syntax.

HK - Most objects do not accept an expression for their NextComponent input. The pop-up description for the input in the Input Editor will tell you what types of input can be used.

Harry

[Robert Mcanany]

I appreciate the feedback! 

A question about avoiding external references in SubModels.  Is that because in the general case you don't control how or where a SubModel will get used, or are there other gotchas? 

On the other question, I wasn't seeing the distinction between an entity and an expression.  Thank you for clearing that up!

[Harry King]

Ideally, the user of a SubModel should not need to know how it is constructed. All inputs to the SubModel should be made directly to the SubModel object, not its components. An external reference in the inputs to a component requires a detailed knowledge of how the SubModel works, breaking this rule. It invites the user to make input errors. This principal is called "encapsulation" in object-oriented programming.

I've attached a revised version of your test model that avoids external references. You can see the changes to the .cfg file using the 'Compare' feature in Notepad++. Note the use of the KeywordList input to SubSub.

Harry

[Robert Mcanany]

Oh, wow I didn't expect that!   I'm studying it now.  I really appreciate your help!