Note: This discussion is about an older version of the COMSOL Multiphysics® software. The information provided may be out of date.
Discussion Closed This discussion was created more than 6 months ago and has been closed. To start a new discussion with a link back to this one, click here.
Can't integrate normal current density nJ over internal boundary
Posted 16 gen 2014, 00:40 GMT-5 Low-Frequency Electromagnetics, Results & Visualization Version 4.3b 4 Replies
Please login with a confirmed email address before reporting spam
Something I can't understand. See the attached trivial model. In Surface Integration 1, if I select ec.nJ from the menu, I get an error message (same with trying to plot it or export it), but if I look up the definition of ec.nJ in Equation View of Current Conservation 1, and enter that expression, instead of ec.nJ, it works fine.
ec.nJ is defined as:
sqrt(realdot(ec.Jx,ec.Jx)+realdot(ec.Jy,ec.Jy)+realdot(ec.Jz,ec.Jz))
The error message I get is:
Exception:
com.comsol.nativejni.FlNativeException: Failed to evaluate expression
Messages:
Post expr failed
Failed to evaluate variable
- Variable: mod1.ec.nJ
- Geometry: 1
- Boundary: 6 10 13 15
Failed to evaluate expression
- Expression: real(mod1.ec.nJ)
Failed to evaluate expression
- Expression: real(mod1.ec.nJ)
Stack trace:
at evaltree.cpp, row 708, ()
at xevaluators.cpp, row 1092, ()
at xevaluators.cpp, row 364, ()
at xmodel_post.cpp, row 4408, ()
at com.comsol.nativejni.xmesh.Xmesh.postInt(Native Method)
at com.comsol.nativejni.xmesh.Xmesh.postInt(Unknown Source)
at com.comsol.nativemph.xmesh.Xmesh.a(Unknown Source)
at com.comsol.post.dataset.u.a(Unknown Source)
at com.comsol.post.dataset.ae.a(Unknown Source)
at com.comsol.post.dataset.ab.a(Unknown Source)
at com.comsol.post.dataset.u.a(Unknown Source)
at com.comsol.post.dataset.d.a(Unknown Source)
at com.comsol.post.numerical.e.a(Unknown Source)
at com.comsol.post.numerical.g.a(Unknown Source)
at com.comsol.post.numerical.g.a(Unknown Source)
at com.comsol.post.numerical.g.computeTableData(Unknown Source)
at com.comsol.model.internal.impl.NumericalFeatureImpl.a(Unknown Source)
at com.comsol.model.internal.impl.NumericalFeatureImpl.computeTableData(Unknown Source)
at com.comsol.post.g.h(Unknown Source)
at com.comsol.post.g.b(Unknown Source)
at com.comsol.post.numerical.g.appendResult(Unknown Source)
at com.comsol.model.internal.impl.NumericalFeatureImpl.w(Unknown Source)
at com.comsol.model.internal.impl.NumericalFeatureImpl.g(Unknown Source)
at com.comsol.model.internal.impl.NumericalFeatureImpl$2.a(Unknown Source)
at com.comsol.model.internal.impl.NumericalFeatureImpl$2.execute(Unknown Source)
at com.comsol.model.clientserver.ClientManagerImpl$1.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
ec.nJ is defined as:
sqrt(realdot(ec.Jx,ec.Jx)+realdot(ec.Jy,ec.Jy)+realdot(ec.Jz,ec.Jz))
The error message I get is:
Exception:
com.comsol.nativejni.FlNativeException: Failed to evaluate expression
Messages:
Post expr failed
Failed to evaluate variable
- Variable: mod1.ec.nJ
- Geometry: 1
- Boundary: 6 10 13 15
Failed to evaluate expression
- Expression: real(mod1.ec.nJ)
Failed to evaluate expression
- Expression: real(mod1.ec.nJ)
Stack trace:
at evaltree.cpp, row 708, ()
at xevaluators.cpp, row 1092, ()
at xevaluators.cpp, row 364, ()
at xmodel_post.cpp, row 4408, ()
at com.comsol.nativejni.xmesh.Xmesh.postInt(Native Method)
at com.comsol.nativejni.xmesh.Xmesh.postInt(Unknown Source)
at com.comsol.nativemph.xmesh.Xmesh.a(Unknown Source)
at com.comsol.post.dataset.u.a(Unknown Source)
at com.comsol.post.dataset.ae.a(Unknown Source)
at com.comsol.post.dataset.ab.a(Unknown Source)
at com.comsol.post.dataset.u.a(Unknown Source)
at com.comsol.post.dataset.d.a(Unknown Source)
at com.comsol.post.numerical.e.a(Unknown Source)
at com.comsol.post.numerical.g.a(Unknown Source)
at com.comsol.post.numerical.g.a(Unknown Source)
at com.comsol.post.numerical.g.computeTableData(Unknown Source)
at com.comsol.model.internal.impl.NumericalFeatureImpl.a(Unknown Source)
at com.comsol.model.internal.impl.NumericalFeatureImpl.computeTableData(Unknown Source)
at com.comsol.post.g.h(Unknown Source)
at com.comsol.post.g.b(Unknown Source)
at com.comsol.post.numerical.g.appendResult(Unknown Source)
at com.comsol.model.internal.impl.NumericalFeatureImpl.w(Unknown Source)
at com.comsol.model.internal.impl.NumericalFeatureImpl.g(Unknown Source)
at com.comsol.model.internal.impl.NumericalFeatureImpl$2.a(Unknown Source)
at com.comsol.model.internal.impl.NumericalFeatureImpl$2.execute(Unknown Source)
at com.comsol.model.clientserver.ClientManagerImpl$1.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Attachments:
4 Replies Last Post 11 feb 2014, 20:09 GMT-5
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
I'm having the same problem, and the same error messages...
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Evgeni,
Not sure why you are getting the error message but attached is your model file with evaluated integral of the normal current density over internal surface.
Both methods of the surface integration of
sqrt(realdot(ec.Jx,ec.Jx)+realdot(ec.Jy,ec.Jy)+realdot(ec.Jz,ec.Jz)) and ec.normJ
work fine and give the same result.
Best regards,
Sergei
Not sure why you are getting the error message but attached is your model file with evaluated integral of the normal current density over internal surface.
Both methods of the surface integration of
sqrt(realdot(ec.Jx,ec.Jx)+realdot(ec.Jy,ec.Jy)+realdot(ec.Jz,ec.Jz)) and ec.normJ
work fine and give the same result.
Best regards,
Sergei
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi Sergei, you're quite right. I'm perplexed how I have mixed up ec.normJ with ec.nJ. While this clears up the confusion in my post, it leaves open the question about the best way to find the current passing through a given internal boundary.
Looking through the Equation View under the different nodes of an Electric Currents interface, ec.nJ is defined at boundaries by such nodes as "Electric Insulation", "Electric Potential", and "Boundary Current Source". Initially I tried adding a Boundary Current Source at the internal boundary, with a current of zero (this is an additional current emitted by the boundary), then ec.nJ is defined over that boundary. But, integrating it, I get zero... In fact, looking at the Equation View, it is defined as zero, therefore no surprise. So, for a Boundary Current Source, ec.nJ is not the absolute current density through that boundary, but the additional current density that the Boundary Current Source adds, and this trick doesn't work.
One way that does work is to define two Electric Currents interfaces to do the job of the original one. The new one takes over some of the domains, including one of those adjacent to the boundary through which we wish to measure the current. Couple it to the original one using just continuity, that is: Electric Potential defined in the interface of V and set to V2 (note that this isn't a Dirichlet BC, it adds two equations, not one, as you can check using Equation View, so this is all you need). Then ec.nJ will be defined as the actual normal current density that we are after, and can be integrated. See the attached model for an example. Note that something like this is also necessary to get accurate fluxes through boundaries using reacf.
Another approach that should work, but I haven't tried it, is to finalise the geometry as an Assembly such that the boundary of interest is a boundary between assembly units, then put a Continuity Pair on that boundary (remembering to define it on the more finely meshed side, else your model might not converge). Then you should have ec.nJ defined on those boundaries.
Looking through the Equation View under the different nodes of an Electric Currents interface, ec.nJ is defined at boundaries by such nodes as "Electric Insulation", "Electric Potential", and "Boundary Current Source". Initially I tried adding a Boundary Current Source at the internal boundary, with a current of zero (this is an additional current emitted by the boundary), then ec.nJ is defined over that boundary. But, integrating it, I get zero... In fact, looking at the Equation View, it is defined as zero, therefore no surprise. So, for a Boundary Current Source, ec.nJ is not the absolute current density through that boundary, but the additional current density that the Boundary Current Source adds, and this trick doesn't work.
One way that does work is to define two Electric Currents interfaces to do the job of the original one. The new one takes over some of the domains, including one of those adjacent to the boundary through which we wish to measure the current. Couple it to the original one using just continuity, that is: Electric Potential defined in the interface of V and set to V2 (note that this isn't a Dirichlet BC, it adds two equations, not one, as you can check using Equation View, so this is all you need). Then ec.nJ will be defined as the actual normal current density that we are after, and can be integrated. See the attached model for an example. Note that something like this is also necessary to get accurate fluxes through boundaries using reacf.
Another approach that should work, but I haven't tried it, is to finalise the geometry as an Assembly such that the boundary of interest is a boundary between assembly units, then put a Continuity Pair on that boundary (remembering to define it on the more finely meshed side, else your model might not converge). Then you should have ec.nJ defined on those boundaries.
Attachments:
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Actually, on nth thought, we shouldn't need to go through the hassle of defining a complementary physics interface or dealing with assembly pairs just to find the current through a boundary.
So I've tried integrating
realdot(sys1.e_n1, ec.Jx) + realdot(sys1.e_n2, ec.Jy) + realdot(sys1.e_n3, ec.Jz)
over an internal boundary, and it worked! (Checked against the method with the two Electric Currents interfaces that I've written about above.)
So my criticism with Comsol in this regard is: why not define nJ as the above expression on internal boundaries? Integrating flux over internal boundaries might be a common-enough requirement, and nJ isn't defined on them anyway. (While the nJ of the Boundary Current Source should be named something else, of course.)
Note that, to the best of my understanding, to get accurate fluxes with reacf on internal boundaries, one still has to use one of the methods described in my previous post.
So I've tried integrating
realdot(sys1.e_n1, ec.Jx) + realdot(sys1.e_n2, ec.Jy) + realdot(sys1.e_n3, ec.Jz)
over an internal boundary, and it worked! (Checked against the method with the two Electric Currents interfaces that I've written about above.)
So my criticism with Comsol in this regard is: why not define nJ as the above expression on internal boundaries? Integrating flux over internal boundaries might be a common-enough requirement, and nJ isn't defined on them anyway. (While the nJ of the Boundary Current Source should be named something else, of course.)
Note that, to the best of my understanding, to get accurate fluxes with reacf on internal boundaries, one still has to use one of the methods described in my previous post.