Discussion Forum

Hi,

example for k.

on the Domain setting instead of using k from material, chose user defined: k1

and define k1 as a global parameter.

the on Study right click, and add parameter sweep. add k1, and give the value of k1: 0 1 2 3
means: the stationary simulation will be repeat for each k1-value. you cannot input 1 2 3 1, smaller value are not allowed. i'm sure that you can find info about it on documentation

if you have k1, rho1 and cp1
paremeter value: 1 100 3000 2 200 4000
means: 1st sweep --> k1=1 rho1=100 cp1=3000
2nd sweep --> k1=2 rho1=200 cp1=4000

i hope it can help you.

regards
akmal hidayat

Thanks for your reply, but I think you misunderstood my question.

What I have is a model with a number of domains, say like a piece of metal in air.
I want to use the same equation in both domains, but they obviously have different properties.
So far, the only way I have found to do this is to define two separate but almost identical functions, each valid in only one domain.
I think that with the materials library and everything, there really should be a cleaner way of doing this.

Under Model->Definitions add two (or more) variable nodes.

Change the geometric entity level to "Domain" and select a different domain for the two Variable nodes. Define as many variables as you like in the table in the Variables section.


Lars Gregersen
Comsol Denmark

Not quite what I was hoping for, but it does work well enough.
Thank you!

Perhaps we can hope for a better connection between materials and mathematical interfaces in 4.3...

Hi

there is something I do not understand fully in your question.

Material properties you can define them as your own defined "Parameters" and enter them directly into the "user defined" fields,

Or you can define them on Entities = domains, respectively boundaries, edges or points under the material node.

Thereafter you can access them directly with their names such as "rho" in a i.e. domain or boundary field, and COMSOL will catch the relevant index matching from the material node and use the correct ones.

If you are working with the mat1.... etc tag names, then you are accessing directly the material nodes in the original order (via tag names) they where entered (and edited). You loose all the indexing taken care of by COMSOL and you do not need strictly use the relation of which material is attached to which domain, respectively boundary (whatever applies).

One thing, if you apply a material to a domain (volume in 3D) i.e. steel, then you need to redefine a "steel2" that applies to the "Boundaries = surfaces in 3D) if you define also material physics on the boundary. As by default in COMSOL the boundaries do NOT heritage the domain material properties, particularly because in "union" mode, you have a common boundary for two adjacent domains, so COMSOL cannot choose by itself which of the two materials to set on the common boundary between the two materials.

It took me some time to understand all this, but once understood, I find it rather logical

--
Good luck
Ivar

...
Material properties you can define them as your own defined "Parameters" and enter them directly into the "user defined" fields,
...

Thank you, but this is only true for the predefined physics interfaces and not the PDE interface.
Also, even in the predefined interfaces I imagine it works only for material properties normally used by the interface, so you can't for example access the Cp property of a material in a electric currents interface - why ever you would want to do that.

...
If you are working with the mat1.... etc tag names, then you are accessing directly the material nodes in the original order (via tag names) they where entered (and edited). You loose all the indexing taken care of by COMSOL and you do not need strictly use the relation of which material is attached to which domain, respectively boundary (whatever applies).
...

Which is exactly the problem...

Hi

OK I now got your point. I was fooled by the fact that I could define linked materials, and properties related, but didn't notice at once they were not active in the PDE environment.

This might be corrected in V4.2, will see soon, if not, I would suggest that you propose it as a "suggestion" to support, I believe too its a valid point, and they do listen to us ;)

--
Good luck
Ivar