Discussion Forum

Hi

I have never tried to merge MPH files, I mostly recreate them, as in v4 it's so quickly done. But one can continue to add a new model in an existing file

--
Good luck
Ivar

I am having the same problem.

To simplify a thermal field simulation I have splitted a geometry into two separeted regions.
Firstly I solve one then I use the themal field in a boundary as thermal source for the second subregion.
After solving the second one I would like to solve both using both solutions as initial conditions for the whole problem.

I have tried to deactivate one region at time, but when I deactivate it I lose the solution for that region.
I also tried to use merge or add component, but didn't work neither.

Best regards
Massimo Camarda

Hi

Even I was trying to copy the geometry (.mph) and import in a new file (.mph) . But I couldn't find an option to import the geometry. I am using version 4.1.

Kirthika, Massimo,

Tinkering with this, I've cultivated a basic procedure that might help:

1. Construct a master model file, which is the importing *.mph file.
2. Construct the model subelement file.
When doing so, be sure to use a placement coordinate system
identical to and aligned with that in the master model file.
3. Save the subelement model as another *.mph file.
4. Export the subelement model file to an *.mphbin (binary equivalent of *.mph)
(right click on Model Builder:Geometry --> select "Export to File")
5. Open the master model file.
6. Import the subelement model *.mphbin file
(right click on Model Builder:Geometry --> select "Import")
7. In Settings: Browse for and import the subelement *.mphbin file.

At this point, the subelement model geometry should now appear as an imported item in the master model, precisely in the desired location. Any changes in the subelement must be done in its file, then re-import per the above procedure to effect the change(s).

However, in the master model file post-import, I noticed material properties assigned to subelement model parts do not propagate into the master model file with the import action -- or if they do, the material assignments are not accessible in the Model Builder window hierarchy under the imported subelement. This would suggest COMSOL MP's indigenous model import routines don't propagate the material library references, even when both models reference a common library.

I also have a hypothesis why math models for your respective applications don't propagate: Boundary conditions change when one geometry is imported into another, which along with materials dereferencing affects the multiphysics analysis.

While COMSOL MP can't rewrite the laws of math and physics, at the very least the next version should be able to propagate all the submodel material properties with the geometry on import. Being able to import *.mph files into larger *.mph files also permits larger, more complex models to be parsed among a team where sufficient licenses exist to do so.

All for now,

Deran

Hi

Indeed COMSOL treats the geometry differently from the rest, as once you have finished your geometry, it is "analysed" and the Entity items are identified (numbered) Materials are assigned to the id, just as physics and BC's, so if you change the geometry, the numbering will change and COMSOL does not always manage to track what you wanted.

Therefore, always check all materials, physics and BC AFTER having changed your geometry (respect the top down sequence of the model tree)

This applies also for 3.5 ;) the "analyise is done in the "geomanalyze()" function

--
Good luck
Ivar

Hi, Ivar.

I don't think we're on the same page yet.

In the master/submodel import paradigm I noted previously, in the master model, the submodel geometry and material composition IS NOT accessible in the "top down sequence of the model tree" beyond an "Import" object reference. That being the case, there is no way I can "check all materials, physics and BCs" to be sure COMSOL fully included the imported model data into the master model.

When it's evident COMSOL employs object-oriented data packets in its processing, it escapes me why an entity numbering reassignment upon import would not retain the material properties assigned to a geometry when both are part of the same object.

When you say "...COMSOL does not always manage to track..." object properties through an import action, per the process description provided, that reveals a logical flaw in how COMSOL handles imported physical data structures -- because importing a smaller model into a larger one still respects the top down modeling tree, or it should, like grafting in a branch to a trunk.

Cheers,

Deran

Hi

certainly I'm not fully at the right page, you are asking too many questions in the same time, and I'm on travel with limited internet access, and no comsol ;(
I cannot test to better catch the issue(s).

But I know that COMSOL is not set up for "super-elements" for the time being, so pruning submodels is not in the way it worked in 3.5 and not yet in 4.1 either. For the future you mut ask your COMSOL rep or support.

And if you think of it, I'm far from certain, that pruning a submodel will not alter the physics of both parts, or the BC or ...

My way is to build several models and to use analytical inital conditions to "link" them via my understanding of the previous results and the model.

What I also do is to use the continuation field as a bolean integer "parameter" generator to have different BCs or material properties. This works OK so long the solver does not decide to take intermediate values and myke my parameter "real" hence messing up my BC flags.

Am I uderstood on thispoint ;)

--
Good luck
Ivar