Ivar KJELBERG
COMSOL Multiphysics(r) fan, retired, former "Senior Expert" at CSEM SA (CH)
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
2010年9月11日 GMT-4 09:59
Hi
well for me ou must define also an "outlet" on the "lower", and an inlet on the upper (same common boundary) and link the physics between both.
You need to get coherent gradients for flux, and i.e heat (if added). Typically by defining either coherent velocity or pressure (but local values, not integrated values average out, then you would lose the flow radial profile). For example outlet no viscous stress for (ns) and inlet pressure "p" for ns2 with "p" from "ns", or use u,v,w as velocities for the velocity inlet of "ns2"
Try it out to see if it corresponds to a "1xns" case (check the mesh density effects on the intermediate border too)
I would have to check if in assembly model with an identity pair between two different (even the same) physics is accepted, as you should not also add other limiting BCs to these boundaries, but if so then I would try to define the common wall as "outlet no stress" for both physics as this constrains the least the displacemetns and in anycase outlet/inlet is only a sign change convention.
To visualise both physics you need to define some new variables, by defining them locally in both physics (Options - Expressions - Subdomain expressions)
Complement (as I tried out some of these BC on the model):
I believe I was too quick there, as NS solves for u,v,w, and p, you would better need continuity for all 4 I believe. Then I see only to edit the equations yourself in Physics Expressions Boundary Expressions on the common surface
Conclusions: I'm not a managing to get it working in a few minutes, would need some more testing ;)
--
Good luck
Ivar
Hi
well for me ou must define also an "outlet" on the "lower", and an inlet on the upper (same common boundary) and link the physics between both.
You need to get coherent gradients for flux, and i.e heat (if added). Typically by defining either coherent velocity or pressure (but local values, not integrated values average out, then you would lose the flow radial profile). For example outlet no viscous stress for (ns) and inlet pressure "p" for ns2 with "p" from "ns", or use u,v,w as velocities for the velocity inlet of "ns2"
Try it out to see if it corresponds to a "1xns" case (check the mesh density effects on the intermediate border too)
I would have to check if in assembly model with an identity pair between two different (even the same) physics is accepted, as you should not also add other limiting BCs to these boundaries, but if so then I would try to define the common wall as "outlet no stress" for both physics as this constrains the least the displacemetns and in anycase outlet/inlet is only a sign change convention.
To visualise both physics you need to define some new variables, by defining them locally in both physics (Options - Expressions - Subdomain expressions)
Complement (as I tried out some of these BC on the model):
I believe I was too quick there, as NS solves for u,v,w, and p, you would better need continuity for all 4 I believe. Then I see only to edit the equations yourself in Physics Expressions Boundary Expressions on the common surface
Conclusions: I'm not a managing to get it working in a few minutes, would need some more testing ;)
--
Good luck
Ivar
Ivar KJELBERG
COMSOL Multiphysics(r) fan, retired, former "Senior Expert" at CSEM SA (CH)
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
2010年9月11日 GMT-4 12:44
Hi again, could leave this like that ;)
OK I'm here in V4.0a (993) but it's the same COMSOL, I have learned two things, first that the new web site does not allow us to upload zip files anymore, well it's like that after a "File reset model" their size decreased so my files uploaded anyhow and the new format is a type of "zip".
file ..._1 two tubes (different sizes than of the original question though) one physics in "union mode"
file ..._1a two tubes in assembly mode with one physics
file ..._2a two tubes in assembly mode with two laminar NS physics
I made two general extrusion coupling operators, one from outlet surface of lower domain (4), and the second from inlet surface of upper domain (9). Then I set the outlet of the lower domain to a velocity field from the extrusion coupling of the upper domain (bidirectional such to get pressure continuity) and I set the inlet velocity of the upper domain to the velocity field of the lower outlet surface via the corresponding coupling variable (also bidirectional)
By comparing velocity profiles and pressures at the interface surfaces everything is similar for all 3 files.
Note I use a constant velocity global inlet, half the Z speed as initial conditions, and a low pressure outlet 100 pa no viscous stress as global outlet on the top
I can also confirm that the default "Identity pair" does NOT work across two similar physics. That is in fact another point I would like to see in COMSOL, a "Global Identity pair" to couple between physics. Handy to make "super-elemet" type models
Finally, to impreove precision it's worth to check that the meshing is identical (and rather fine i.e. use copy mesh in doubt) on the two "super-pair" boundaries (4&9)
--
Good luck
Ivar
Hi again, could leave this like that ;)
OK I'm here in V4.0a (993) but it's the same COMSOL, I have learned two things, first that the new web site does not allow us to upload zip files anymore, well it's like that after a "File reset model" their size decreased so my files uploaded anyhow and the new format is a type of "zip".
file ..._1 two tubes (different sizes than of the original question though) one physics in "union mode"
file ..._1a two tubes in assembly mode with one physics
file ..._2a two tubes in assembly mode with two laminar NS physics
I made two general extrusion coupling operators, one from outlet surface of lower domain (4), and the second from inlet surface of upper domain (9). Then I set the outlet of the lower domain to a velocity field from the extrusion coupling of the upper domain (bidirectional such to get pressure continuity) and I set the inlet velocity of the upper domain to the velocity field of the lower outlet surface via the corresponding coupling variable (also bidirectional)
By comparing velocity profiles and pressures at the interface surfaces everything is similar for all 3 files.
Note I use a constant velocity global inlet, half the Z speed as initial conditions, and a low pressure outlet 100 pa no viscous stress as global outlet on the top
I can also confirm that the default "Identity pair" does NOT work across two similar physics. That is in fact another point I would like to see in COMSOL, a "Global Identity pair" to couple between physics. Handy to make "super-elemet" type models
Finally, to impreove precision it's worth to check that the meshing is identical (and rather fine i.e. use copy mesh in doubt) on the two "super-pair" boundaries (4&9)
--
Good luck
Ivar
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
2010年9月14日 GMT-4 09:12
Hi,
Thanks so much for your help. To be sure that I understood what you did, I remodeled it in 3.5a. It also works :-)
I attached the solution as "Twice_same_application_mode_OK.mph"
I now tried to add the deformable mesh application mode, as this was the reason why I asked this question (twice same application mode, once in the reference mesh, once in the deformable mesh, with common boundary).
I have deactivated the deformable mesh in the subdomain which must be computed in the reference mesh.
I have attached the file as "Twice_same_application_mode_with_ALE.mph". I get the following error message, which has not been reported in the forum so far unfortunately:
Error: 6070
Local mesh transformation failed.
I tried to solve it in 4.0a, and it worked... Any idea what the reason for this error message could be in 3.5a?
Thanks,
Alois
Hi,
Thanks so much for your help. To be sure that I understood what you did, I remodeled it in 3.5a. It also works :-)
I attached the solution as "Twice_same_application_mode_OK.mph"
I now tried to add the deformable mesh application mode, as this was the reason why I asked this question (twice same application mode, once in the reference mesh, once in the deformable mesh, with common boundary).
I have deactivated the deformable mesh in the subdomain which must be computed in the reference mesh.
I have attached the file as "Twice_same_application_mode_with_ALE.mph". I get the following error message, which has not been reported in the forum so far unfortunately:
Error: 6070
Local mesh transformation failed.
I tried to solve it in 4.0a, and it worked... Any idea what the reason for this error message could be in 3.5a?
Thanks,
Alois
Ivar KJELBERG
COMSOL Multiphysics(r) fan, retired, former "Senior Expert" at CSEM SA (CH)
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
2010年9月14日 GMT-4 16:26
Hi
Well I cannot really tell, but I noticed that in V3.5 your ALE is fully constrained on all surfaces (not the volume) and it implies by default "non-ideal" couplings, which could give some clues why the mesh link does not match.
I tried to solve in 2 steps, the ns first and rest for next phase, but I got the error message at once. Furthermore if you look at the Physics Equations Settings - Boundary Equations you will see that there are one-way links betwen x and X that is different for the two domains, ut this is what I wouldexpect anyhow
While in V4 the ALE is constraing the mesh in all volume/domain, hence no need neither any possibilities to lock it on the borders. But in this case, for me the ALE behaves as a normal fixed mesh, and that is probably why it solves without any error message.
You will probably need to get help from "Support" for this one ;)
--
Good luck
Ivar
Hi
Well I cannot really tell, but I noticed that in V3.5 your ALE is fully constrained on all surfaces (not the volume) and it implies by default "non-ideal" couplings, which could give some clues why the mesh link does not match.
I tried to solve in 2 steps, the ns first and rest for next phase, but I got the error message at once. Furthermore if you look at the Physics Equations Settings - Boundary Equations you will see that there are one-way links betwen x and X that is different for the two domains, ut this is what I wouldexpect anyhow
While in V4 the ALE is constraing the mesh in all volume/domain, hence no need neither any possibilities to lock it on the borders. But in this case, for me the ALE behaves as a normal fixed mesh, and that is probably why it solves without any error message.
You will probably need to get help from "Support" for this one ;)
--
Good luck
Ivar