Discussion Forum

Yes this is VERY easy to do but through the integral feature of Comsol NOT the PDE mode

integrate f(x) once you get u' [ up to one constant]
twice you get u up to 2 constant this is done easily with the operator dest (x) the trick is to write properly the function to integrate in order to simplify the resolution of the 2 other conditions on a and b
except in some special circunstances, they will have to be resolved through "global" algebraic equations.
This is really a SIMPLE excercise and you should go through the details yourself learning the features you need in the documentation in the process.
BUT if this is not part of a bigger problem, I fail to see the interrest of using comsol to resolve this.
hope this help
jf

Thanks for your reply, Jean. Yes, it is only an example of an entire class of problems where the integration constants are specified differently than simply on both boundaries of the domain. There are many ODEs, including especially the ones where the domain is [0,inf), where you only know the BCs at the origin, but you also know that this is enough to uniquely specify the analytic solution. The question is how to do it in Comsol? I couldn't find anything in the documentation that addressed this somewhat elementary problem.

You write "...the trick is to write properly the function to integrate in order to simplify the resolution of the 2 other conditions on a and b except in some special circunstances, they will have to be resolved through "global" algebraic equations."

If it's not too much trouble, it would be very helpful, and perhaps of general interest to others as well, if you could step through the procedures for solving an illustrative example problem using the dest(x) operator, say, for the u''(x)=2, u'(0)=0, u(0)=0 example.

Many thanks in advance.

Kay,

Find the example you requested attached below. it solves the problem you asked foron the interval [-2,3] as an example
again it is absolutely obvious WHEN you have spent the time learning comsol. [ I have been using it myself for only 3 months so it is not too complicated but require work ]
[ and if more experienced user look at the case maybe they will simplify it.
the PDE is dummy and serve NO puprpose except triggering the solver.
mesh to whatever accuracy you want
plot u and uprime to see the results
to undertand the codingof this example you need to be familiar with coupling variables both integration and extrusion variable with general transformation and difference between local and global context and what the operator dest is

Hope it will get you started
jf

Jean,

MANY thanks! I greatly appreciate the worked example and the pointers. This will be a big help. Now, back to the books....

Jean, BTW, could you recommend any good reference materials about Comsol besides their documentation? Thx.

I am not aware of any good[ or bad...lol] reference on Comsol beyond the doc. that does not mean it does not exist, just that I dont know it
jf

Jean and other users:

FWIW, I bought two recent books devoted to Comsol modeling.

1. Pryor, Roger W., "Multiphysics Modeling Using COMSOL"

and

2. Zimmerman, William B.J., "Multiphysics Modelling With Finite Element Methods"

The Pryor book discusses many models, but doesn't go into the theoretical
foundations of FEM modeling and how they are implemented in Comsol,
usually discussing only very simple models. I found it to be only marginally
useful in terms of being able to generalize to other models beyond the specific
ones treated in the book.

The Zimmerman book, on the other hand, lays the theoretical background
necessary for understanding the models he discusses and has a fair amount
of material about how to use Matlab to extend functionality beyond that
provided by the Comsul GUI. This book is very useful as a adjunct to the
Comsol documentation. My only criticism of the book is that the Index is
not detailed enough to be able to locate where primary definitions are
located in the book.

On a scale of 1-5 stars, I would give the Pryor book 1 star, and the
Zimmerman book 4 stars.

I find the Comsol documentation to be very difficult to use. It does not
take a systematic tutorial or pedagogical approach, nor devote enough
space to providing precise definitions of terms, along with graphic
illustrations showing the relationship between, for example, nx and the
placement of nodes in an element. There is no discussion of the code
used for upwinding, as another example, instead leaving it up to the
student to figure it out for himself.

Zimmerman's book is a very useful adjunct to the Comsol documentation
and would recommend it to anyone needing, like me, more explanation
about Comsol than is provided by their documentation.

Hi

I have several of the books mentionned aboveand below, and basically agree with the rating, and find them good to play with and for the extra examples, you have a/the long list here:

www.comsol.com/academic/books/

(search more on the COMSOL web site its full of good references !)

I have got most of my COMSOL training via the COMSOL courses and even repeating some after a year or two (but I must admit that my trainers here in Switzerland and in France were excellet physiscist/mathematicians, really knowing well their subject), from the COMSOL Conferences and the Forum ;) but all this requires (a lot of) time.

My main comment vis à vis the COMSOL documentation is that there are quite some underlaying assumption on the order/sequence things are done inside the soft, on the exact mathematically expression behind the GUI' that still confuses me, and I'm often getting lost in the numerous solver settings, but they are handy to have, hope V4 will calrify better.

But to do multiphysics, one really need to understand multiple physics too, it's not just structural with gravity load and exceptionally a temperature any longer

Have a good reading
Ivar

Thanks Ivar for your comment. What I haven't been able to find anywhere
is a good tutorial discussion with diagrams that show PRECISELY the relationship
between such things as, but not limited to, normal vectors and the underlying cells,
and diagrams to supplement the words on the definitions of "up" and "down", etc.
This would appear to be an elementary issue, so somewhere should be some
material that provides the necessary definitions and diagrams. Something even
as simple as the precise way a derivative is actually computed based on the
shape functions and its underlying parameterization would be extremely useful.
Maybe it's actually laid out in detail somewhere, but I have not found it. As I
mentioned previously, a detailed description of the various upwinding, streamline
diffusion and cross wind diffusion would be very helpful. I've studied the actual
Comsol code for these, but having only word descriptions instead of precise
definitions and accompanying diagrams about the various variables (unx, etc.)
and their geometrical meanings leaves me with less than a satisfying belief
that I really do understand them. The models in the Model Library are too
complicated to be helpful for tutorial work. The models work as advertised,
but change one parameter and POOF, they stop working with little clue as
to the reason.

Someone somewhere knows this stuff, which would be necessary for designing
shape functions possessing certain desired properties. It would be good to
know where they learned it.

My own interest is in 2-D adaptive spacetime meshing. Here, there has to be
a constraint imposed forcing the system to respect causality, so that, e.g., time
derivatives cannot be computed using information that is downstream in time,
i.e., lies in the future, and of course this applies also to the downstream boundary
condition along the time axis. Of course, what one would really like to do is
fully 3-D spacetime meshing, but this would require 4 dimensions to describe
(3 space + 1 time), and require 4-dimensional shape functions. Hence my general
interest in how to design shape functions.

It would also be really great if the an indexed Help function could be
developed for the GUI that works like other modern software packages,
instead of sending the user off to a browser with links to the documentation.

Hi

I can only agree with you, my main difficulty to date, learning COMSOL, is that I'm missing some fundamental explanations on the definition of the basic elements i.e. such as the correct integral definition of a coupling variable: on the nodes or on the shapes ...

for the up & down, I have managed so far by saying "inside domain = down and outside domain = up"

I believe that for the COMSOL authors, this has become so trivial for them , that they forget that for us using the software, not having access to the interiour, we are missing some of these fundamentals.

I have found some further explanations if you look for the "Matlab PDE toolbox" old doucmentation on the web, the precursor of COMSOL

I can only suggest to you to go to the Comsol conferences, discuss it out directly with the COMSOl "designers", i.e. try to catch Nils Malm and be prepared to have an intense math-physics-PDE discussion, in anycase of high interest.

And pls send your suggestions to COMSOL, if we are many with the same demands these people really set in an effort to serve us users well, I have seen many of my suggestion being implemented.

Good luck
Multiphysics require some (re)learning/training, but it's really worth it
Ivar

Agree 100% with you guys...

simplistic model even non physical ones... for some complex feature will be very important to test /understand/learn it....
In fact I just sent a request to comsol support yesterday requesting EXACTELY such a model for some advanced setting of the time dependant solver that "refuse to work" :-) for me even if I believe I do exactely as the doc says.... but the documentation is way too sketchy on the solver in my opniion [ already said that to comsol by the way]

In fact when I want to use a new feature or find a problem I always [try to] learn the feature or reproduce the problem on a minimalistic model [ like the one I build for you on this thread[ that I build for the purpose [ this can be done usually quiet rapidly EXCEPT for the part you need to learn or fix.. of course :-)]
this way you remove the possibility of error in another part of a complex model that you will misinterpret and that wil get you confused focusing on the problem at hand . These models does not have to be physically meaningfull ...just numerically sound
jf

Ivar and Jean, thanks for your supportive thoughts. It's a problem of pedagogy. The general rule is, start simple with lots of elementary and trivial examples and work your way up, one step at a time. The examples in the Model library, while they work as packaged, are too complicated to be useful for basic instructional purposes. It's like going to automotive mechanics school and being presented with a Ferrari to use for learning the basic principles of how piston engines and brakes work, when what's really needed is a 2CV.

An example of the kind of elementary thing I've not been able to find (perhaps I haven't been diligent enough) is how differentiation is performed, say d(u,x). I THINK (but don't really know) that it must of necessity involve the derivative of the shape function, but it would be good to know the details. Along these same lines, the precise definition of the test function and how it enters into calculations is a little vague. According to the documentation, I surmised that transforming a PDE into the weak form involves multiplying across some "arbitrary" v, integrating by parts, and then substituting test(u) for v wherever it occurs, test(ux) for vx, etc. One finally figures this out after going back and forth between the documentation and examples enough times, but it would be preferable to have it spelled out in simple and less abstract terms, including reminding students in multiple places that the v in question isn't just any old arbitrary function, but a specific shape function that is nonzero only inside a single cell (this requires explaining a little better the mathematical concept of "compact support"), and the integration involving test(u) is actually an integration of the product of the normalized shape function and u (I think). It would be good to see this spelled out in gory detail.

I realize this is boring stuff for the Comsol designers, but teaching Lower Division physics classes is boring, too, but that doesn't absolve me of the responsibility of tailoring my lectures and presentations to the level of the students who are still on training wheels. There are people who specialize in writing text books with attention to these kinds of things. For example, there are many dozens of books on how to use Matlab, many of them really excellent in their pedagogical approaches. (And Matlab has a superb Help feature, as well.) Perhaps Comsol could consider something along these same lines, as well.

My apologies for seeming to rant, but it's only a measure of my frustration. I first bought Femlab seven years ago but gave up after a few months over the impenetrability of the documentation. I know several other people who have had exactly the same experience, starting out, giving it a good shot, and then giving up for the same reason. These were not novice programmers, but FDTD MHD modelers with decades of experience. They are well versed in the mathematics of PDEs and fully capable of transitioning to FEM methods with a bit of guidance. Comsol is losing potential users like these on account of their documentation. I've looked at other packages such as ANSYS and OpenFoam etc., but their documentation is equally obscure, if not worse. But since I'm an avid Matlab user I finally decided to have another go at it, with version 3.5a. However, I see that the latest documentation is essentially unchanged from what it was seven years ago, so obviously documentation isn't high on their list of important things to do.

Aside from my own personal experience, the broader issue is that the steep learning curve coupled with the absence of good tutorial materials is a barrier to entry into this field, and is likely costing Comsol business. Were an easier path available to learning the software there would be a lot more people jumping into the field and help Comsol to secure it's place as market leader in the field.

Hi

A basically agree with you all along, strongly for the basic training methodology and lack of basic introduction in COMSOL, I have also discussed this a couple of times with the COMSOL people (the conferences are really THE place where to meet them), and I also agree that they are loosing a lot of potential clients like this.

But in their favour, I can understand that for so few people as they are (which is also why COMSOL is still affordable for purchase, in my view) it's difficult to programme and to rewrite all PHYSICS and I believe they had hoped for more help from the universities and persons out there to write more books and give the basics, this is coming, but slowly, perhaps we should help too for the moment my way is the forum as I learn a lot like this ;).

My first experience with Matlab 25+ years ago was also decieving (from the doc and support point of view), but they had finally a rather primitive numerical maths at that time, the toolboxes came and got improved (concerning the documentation) really after 10 years and I used just a few, not a dozen at once, in the mean time Matlab/Matworks company grew out of control and the price of their product too, even if I very much appreciate it and find it great. I hope COMSOL will NOT get caught in this cost spiral.
Talking about NASTRAN and ANSYS that I have used sporadically (regularly for the review of result) over the last 20 years I can also say that if the old courses of the former were rather basic and stepwise to follow, the ones from the latter have never fully convinced me, and ANSYS has remained a sa "Black Box" tool for me, but still of high quality, for both of them. Nastran had the basic COMSOL approach at its very beginning with access to the matrices, control simulation possibility, lump parameters etc, but it got rapidly pushed into the click-fill-in design ready for engineers being efficient in one or two domains.

There is also one major thing here:

If we consider ourself as an independent (physicist/systems) engineer doing our job alone, then we would need some good tools, my reply would be: SolidsWorks for the CAD, Matlab and Simulink for the numerical, Maple and Maplesim for the analytical and COMSOL for the PDE multiphysics. But if you add this all up as purchase price and maintenance price and leave a little for yourself to survive, then at what price could we sell ourselves ?
We would simply NOT be competitive on the market.
And being part of a bigger company is not really solving the issue, it's difficult to share these tools among several as we need 2-3 at the time, running 3x8h is possible for largeest companies running the clock around the world, but most companies are NOT like that, and I do not feel as I'm a special guy so that I can, with these tools alone, feed 5-10 others "cheaper" persons so that together we get to an eacceptable rate.

And we are also building a 2-3 level society like this too, for those not managing to purchase these tools, will they manage to follow, as for me COMSOL is really opening up for a higher level physics understanding.

Well back to the basics of COMSOl training, I agree that often even their courses are too high, I had expected an introduction course, not all about the clicks and of the type of Prior last book, but of intense mathematical expalnations of the basics behind the essentiual GUI windows of COMSOL. I have noticed that the presentation of V4 is evolving more in this direction (or is it me that understands more with the time 3+1/2 years) but still is not there either.

So my dream is to find a professor at one of the universities here around to set-up such a thing and perhaps to collaborate, or I get a PhD student to coach and put part-time on the subject, but my principal job is systems engineering development of new products and technology transfer to industry, for a private company, not really training others on COMSOL, even if that is fun (I must admit I havnt had so fun doing physics since I studied it a long time back, now I can plug my items in-there and get the math done in a couple of seconds and really concentrate on how our models are behaving with resepct to what nature is showing us.)

Last thing: by replying on the forum, and repeating for myself to find the right answers, I notice that I'm getting down to the level that I test out one item at the time, and I'm less tempted to start complex, because basically the main error out there (and I must admit I do too for my own models) is that one start to couple 2-3 physics at once, before one really understand how just 1 physics is treated. By the way the "physics" appraoch in V4 is better layd out, I like that, (I have heared it's for next month, but it means 1 month training to understand again ;) and it means also slightly more "thinking" and "understanding" first before we manually couple all the physics in there.

So the question: how can we set up a good introductionary tutorial matereial on the Model Exchange forum, a couple of people out there have started !

It could even be a "world" commitment with participants all around ?, the COMSOL Wiki ?

Nothing is better than helping yourself

have a nice week-end
Ivar

Comsol wiki will be definitively of great interrest and maybe also will generate de facto a bigger involvement from comsol itself just to make sure the info there is right..[ Comsol being a commercial product ,they will have an interest in there but could also benefit from contributions from the user ... should be a win win .

jf

Hi

in fact by a quick google/bing I found this, that is a starting point, now how to link something like this with the corresponding GUI's and items within COMSOL, plus simple examples ?

en.wikipedia.org/wiki/Finite_element_method
en.wikipedia.org/wiki/Hp-FEM
en.wikipedia.org/wiki/Partial_differential_equations

in French it's translated here I see
fr.wikipedia.org/wiki/M%C3%A9thode_des_%C3%A9l%C3%A9ments_finis

I believe it could even start at a basic Vector Algebra level, with curviline coordinates in space, to link to the basic integration variable. I have noticed that in the postprocessing, there is an "advanced" tab that allows to select summation over nodes, with or without higher order terms, or "true" integration of the variable based on the element shape orders (?) This choice is not there in the Integration Variable that I assume are then "integration" and not summation based, but I beleive to remember that in the V4 beta there was an option for selection summation or integration for the "operators" that will replace the "integration variables"

And there is ther "smoothing" feature to use or not the average values on the edge from the two adjacent boundaries, respectively on the points from the adjacent edges.

These are really basic items, but I too prefer to have them clearly written out to know upon what I stand (this could be my scandinavian origine showing up, we always started to dig all the way to hard granite stone before we started building up our houses, the swedes have less granite, or its far deeper, I believe ;)

Ivar

Some really simple example problems would go a long way toward explaining a number of concepts

Most people will approach FEM modeling with some basic knowledge of ODEs, so how about the following?

Consider the simple problem I posed at the beginning of this thread u'' = 2. There are two integration constants that are needed to solve this, and they could either be values or slopes or some combination of them specified somewhere within the domain. It would be a very good exercise to work this single problem for all possible ways of specifying the boundary conditions so as to be able to see what's required for, say, boundary values not only at the ends of the interval, but also for values specified somewhere in the interior, etc. Part of the problem here is that Comsol insists on specifying BC at both ends of the intervals, but this is an artificial restriction from the point of view of the underlying mathematics, and they can be specified anywhere within the domain. It would be good to see how to treat such situations. Jean has graciously shown one way to work it using the dest() operator and extrusion variables, but there must be simpler ways, too. It would be very useful to see a number of these different ways. Remember, it's not the actual solution of this particular problem that's most important here, it's the exposure to the underlying FEM concepts and how they are expressed in Comsol, and the simpler the problem that can be used to illustrate them, the better.

Hi

I have never had the impression that "Comsol enforces to define BC at the ends" (but I would have to check more carefully) for me the programme is rather systematic saying BC are define on next geometrical sublevel, but nothing on realtive positions. What confuses, perhaps, is that you define BC only on existing geoemtry entities, and mesh nodes are not directly accessible if they are not defined as "hard points" = existing geometries.

I like the way COMSOL put orders in things, and not messing it all up as other programmes do:
Geometry is clearly separated from meshing,
Meshing is defined as geomtrical simple entities: tri/teth/quad... and
Higher order element implementations such as tri-3nodes, tri-4nodes, tri-7nodes, quad-4nodes, quad-5nodes, quad-9nodes ... (now I'm too generous, not all exist in COMSOL ;) are define as element shape functions and not mixed up with the meshing,
Material properties are defined separately, and by default on all items (will come in V4 I have seen) but you can locally override.
Finally solving and postprocessing are separate, and selectable in detail (the later was also well improved in the peek view of V4 we were presented last fall at the conference.

In fact I noticed that in V4 they have even more systematised this approach, but also changed a couple of things, such as "h" dissapears for the (Dirichlet and general Neumann) BC definitions.

Now back to the end BC issue: if you define a geometrical "interiour boundary" that you activate explicitely as it is by default "inactive=forced to continuity" you can ther define your BC as Neumann/Flux or Dirichlet/Value or any combination thereof, no ?
After some testing, in fact NO you can define a Dirichlet value but flux is the same on the left and right side of the boundary (or up/external/outwards and down/internal/inwards normal w.r.t the element) by continuity !
A first implicit hypothesis, and is therefore Flux NOT DIRECTLY defined by an interiour BC

If I make a 1D Coefficient form PDE, put c=-1 and f= 2 (all other =0), make the geometry a line from 0 to 1 and add a point at 0.33, I then define two BC conditions for the point at 0.33 a value and a slope (q=0,g=2,h=1,r=1) and leave the ends free, off you go, no ? or have I missed a point:

YES I have:
I just realisd that COMSOL forces a "Zero Flux" on the two ends (second COMSOL hypothesis) and I cannot remove it, I understand this as COMSOL wants to stay "physical" with isolated extremities, so one must/could use a Weak term here to "float" the end ux values. And as I have only defined one second order equation, when I solve I have a discountunity of ux at my interiour boundary point, while my mathematical (default) sens would have had continuity here and "floating" derivatives at the external boundaries, the step I get at my interiour boundary is the value of the LM1 the weak constraint value (when turned on in the physics- properties).

My conclusion: my "mathematical" and "physical" natural default approaches are different, we use different initial conditions hypothesis when we look at the same equation from a "mathematical" or a "physical" point of view, and obviously I do no longer even notice it

I must admit that I seldom do my basic math with COMSOL, I use usually Maple and Maplesim (also as verification for my COMSOL cases which are very "ingeneering oriented), perhaps I should do more, it would give me a better understanding of the COMSOL interiours, I agree. I will have to reread my "modeling.pdf" again :(

so how to get around ?
- Jean gave one way with the dest() and the integration coupling variables,
- a first order equation is trivial as the boundaris can then be fully defined,
- the single second order equation d^2u/dx^2=u''=cte , in a general mathematical sens is not that easy to solve for all cases, because of the COMSOL "physical" hypotheses of zero flux at the external boundaries, you coulod add a second linked variable v=du/dx and set conditions on this one too, or to set weak constraints on the flux of the external boundaries (?)

Well in conclusions, after my mess hereabove :),
yes solving in aa general mathematical sens such a trivial 2nd order equation is not trivial in COMSOL as when I wan to go into detail I get stuck with the "implicit default hypothesis in COMSOL"

Will have to come back on this one, I will raise the question on the COMSOL workshop I'm following tomorrow at the EPFL ;)

Have still a nice week-end
Ivar

Hi again

what about this way:

How to define :
u''=d^2u/dx^2=2 over the line 0 to 1, with the BC at the point x=0.4 u=0.05 and u'=0.5

Set up a model with PDE coefficients with two variables u & v

draw a line from 0 to 1, and add a point at x=0.4

On the two elements 1 & 2 set:

c=a=ea=da=alpha=gamma=[0 0 ; 0 0 ]

beta= identity =[1 0 ; 0 1]

f = [v ; 2]

basically this means two first order equations:

du/dx = v and dv/dx = 2

Then as BC's:

External nodes 1 & 3: Dirichlet and all "0" on all matrices

intermal node 2: q=g = all 0, h=identity, r=[0.05 ; 0.5] the BC's for u and u'

With this there is no restriction on the external boundaries and you can set de value and its first derivative anywhere within the domain

Is this cleaner ?

Ivar


PS to go one step further, compare the result with the following one:

Set up a model with PDE coefficients with one variables u

draw a line from 0 to 1, and add a point at x=0.4

On the two elements 1 & 2 set:

beta=a=ea=da=alpha=gamma= 0

c = -1
f = 2

basically this means the same, but this time single second order equation:

d^2u/dx^2 = 2

Then as BC's:

External nodes 1 & 3: leave as is default (zero flux or du/dx=0) (different from above)

intermal node 2: q=g = 0, h=1, r=0.05 the BC fixing u (bot not u', different from above)

no BC on the first derivative as the flux are already defined by the external nodes

Then turn on weak constraints => Physics - Properties weak = ON

solve,
plot u, ux, uxx and postporocess lm1 on the interiour point "2",

compare value of the Lagrange multiplier LM1 to "ux" at and around point 2
reread the boundary conditions in the doc (guide.pdf, modeling.pdf) look at the mariable "greek mu" (=Lagrange multiplier ) on the generalised Neumann conditions

Hi again

I had a discussion here with our local COMSOL specialist Sven (and head of the local COMSOL office), he pointed out that if we read carefully the modelling.pdf page 247 and on (v3.5a) the BVP the way it is defined in COMSOL, which is a widely accepted way, require that the external boudaries = dOmega to be define.

It is mathematiacally proved that in this way we have then an unique solution inside, while if we take and only define the internal boundaries, in all generality (and not restricting us to 1D), the solution might not be unique.

In 2D the issue is perhaps more evident, as the flux is defined only projected on the perpendicular vector "n" that means that one dimension is still free and we are not defining enough DoF's.

Now, what I have discovered with this is that by default when I define fluxes on interiour boundaries they have no direct effect (they only scale the Langrange multiplers, if we look at them), due to the condition of continuity of flux on interiour boundaries.

This clearly limits the mathematical extend to solve for all cases in full generality, but by reexpressing the equations as above as two first order we can still get the desired result out.

I have already read through, numerous times, the modelling.pdf doc, but I still learn new things ;)

Remains to find how to correctly find the third path: "float" the fluxes at the boundaries, via I expect a weak formulation, and force a flux on the interiour, and solve this 1D issue, as example, something for next week-end ;)

Have a nice day
Ivar

Hi again,

My preferred lecture closest to COMSOL's math notation is:

"Introduction to computation and modeling for Differential Equations", by L. Edsberg, Wiley, 2008

And as COMSOL cookbook well written with math references is the:

"Multiphysics Modelling with Finite Element Methods" by B.J. Zimmerman, World-Scientific, 2006

Have a nice day
Ivar

Hi,

Ivar told me about that "simple problem" during yesterday's COMSOL workshop at EPFL Lausanne. On such occasions we COMSOL people typically deal with 20+ attendees hungry for tipps and tricks. I could not answer in due detail right away. However, in the eveneing after a good glass of wine in a cosy Lausanne restaurant the "subprocess" in my head reported back even two results how to conveniently solve this problem.

First we need to understand that the problem constitutes not a classical boundary value problem as typically solved with COMSOL. Nevertheless it can easily be solved with very simple means - you dont need any dest() operator or splitting into two equations and the way is just as straightworward as writing it down with pencil an paper.

I attach a brief description and two models for COMSOL 3.5a.

Best regards,
Sven

Thanks Sven

Good that you enjoy the local wine Sven, it's better here in the "welch" region no ;)
I'll take a closer look at your files, tonight

For further references, the book of Pr. D.W. Pepper & J:C. Heinrich: The Finite Elements Method, Basic Concepts and Applications, Taylor and Francis, 2006, goes through the Gallerkine FEM method, step by step with simple (but still quite complex for the detailed formulation) examples. It discusses also shortly the flux on interiour boundaries (being ignored by default).

Now, I had also some wine yeterday, the retirement party of a longtime colleague, and that did also give me some thoughts, so I'll try to use the Draw "assebly" mode next time I have a moment, as then you can access the interiour boundaries, but that's perhaps aslo what you are saying

Have a nice day, and thanks for the nice presentation last Monday, when are you starting the "COMSOL College" and travel from uniersity to university within CH ?

Ivar

Thanks Sven,
this example [ including your contribution] is I believe a good example of what we , on the user side, have been fingering as what we see as a "hole" in Available Informations supporting our"day to day" learning curve, between the documentation on the one hand, and the application oriented model you provide on the other hand, very important to practically start but almost useless to learn what works better or how to develop an "unusual" model

Comparing my initial solution [ using dest..] with your proposed solution make me understand things that will have taken much longer for me to grasp otherwise.....

So I will throw another simple question for the community related to how comsol work... hopefully some people wil have some ideas on that ...

IN my multiphysics modeling work [almost always 2d], I often have to include "simple" 1d pde of the kind du/dx=f(V,x,t) to calculate a "load"term on the boundary of a domain . V here is a vector composed of other variable calculated elsewhere within comsol.
The problem is well posedwith dirichlet on one point which is physically meaningful in my case

to solve this equation I can use
weak pde boundary mode OR
integrate f(V,x,t) on the boundary.[ with the dest operator..]

I have tried both approaches and found that they were practically very different while they are formally equivalent.
[ I understand that in the PDE mode u is calculated as an indepenfdant DOF while with integration it use the other variables] and that changes the matrice in an important way.
The problem I find is in understanding these differences, for if I use "simple problem " with known solution I find that the approaches give the same solution but when I use more complex problems with no known solutions I find different solutions.. everything else being equal except for using a pde or an integral....

So my question, regarding the choice of using a pde or an integral is here a "better way" or a "reconmmended way" or not?
If somebody as the answer it will be very much appreciated
Thanks
JF

Hi JF,

my personal recommendation would be to use the weak form if you profoundly know what you are doing and computational ressources are an issue. In all other cases integration coupling should suffice.

Indeed integration coupling is comparatively easy to use but changes the structure of the Jacobian, usually fills it up, resulting in higher computational expense. Weak terms, on the contrary, typically require some insight but are elegant and can help you saving resources because they use integral formulation inherent to the FE formulation.

One should also be aware that "weak" and "strong" also distinguish classes of solutions, a PDE solution is always also a solution in the integral sense but not vice versa. Although in practical cases this is rarely an issue in engineering work one should be aware of this difference.

Sven

Thanks Sven
I am at the moment NOT profoundly knowing what I am doing with Comsol... but learning... :-)
your comment is VERY helpful for me
just wanted you to know that
JF

Hmmm...I was away for a few days and just discovered the great responses above. It'll take a while to digest them all, but thanks to everyone for jumping into the fray. BTW, I also have Zimmerman's book and it's really pretty good, typos and all (and even despite the fact that he gets "contours" and "streamlines" confused, and the index could be more detailed).

...
First we need to understand that the problem constitutes not a classical boundary value problem as typically solved with COMSOL. Nevertheless it can easily be solved with very simple means - you dont need any dest() operator or splitting into two equations and the way is just as straightworward as writing it down with pencil an paper.

I attach a brief description and two models for COMSOL 3.5a.

Thank you very much Sven. Very helpful. I think I see the way forward now for this simple problem.

There are useful applications for which the BV cannot a priori be defined. For example, consider the 1-D Poisson's equation for a delta function source at some location in the interior, but for which you would like to determine the free space solution. In this case, one could certainly calculate the Green's function form of the potential and then evaluate them at the boundaries and manually insert them as Dirichlet conditions. But it would seem that a cleaner way, and in the spirit of the example you provided, would be to calculate them, not on the actual boundaries, but rather at, say, two points close to the source and then integrate out to the boundaries. If then one had a continuous distribution of sources one could then solve the general problem by simple summation.

One would think this could then be extended to 2-D, where one now constructs a small circle of fixed radius around each point source, for which the potential would be known, and then march on out to the boundaries the same as with the 1-D solution. The same would hold for 3-D.

Of course, this would require being able to programatically construct the interior boundaries in these cases. Is there a way to do this? The ability to do this would be very useful for solving free space geometries, which is my primary interest, and for which there are no outer boundaries (except at infinity).

Hi again

I had a discussion here with our local COMSOL specialist Sven (and head of the local COMSOL office), he pointed out that if we read carefully the modelling.pdf page 247 and on (v3.5a) the BVP the way it is defined in COMSOL, which is a widely accepted way, require that the external boudaries = dOmega to be define.

It is mathematiacally proved that in this way we have then an unique solution inside, while if we take and only define the internal boundaries, in all generality (and not restricting us to 1D), the solution might not be unique.

In 2D the issue is perhaps more evident, as the flux is defined only projected on the perpendicular vector "n" that means that one dimension is still free and we are not defining enough DoF's.

Now, what I have discovered with this is that by default when I define fluxes on interiour boundaries they have no direct effect (they only scale the Langrange multiplers, if we look at them), due to the condition of continuity of flux on interiour boundaries.

This clearly limits the mathematical extend to solve for all cases in full generality, but by reexpressing the equations as above as two first order we can still get the desired result out.

I have already read through, numerous times, the modelling.pdf doc, but I still learn new things ;)

Remains to find how to correctly find the third path: "float" the fluxes at the boundaries, via I expect a weak formulation, and force a flux on the interiour, and solve this 1D issue, as example, something for next week-end ;)

Have a nice day
Ivar

Hi Ivar,

I'll post my thanks here to all your posts concerning this "simple question." Thank you for pursing this and bringing it Sven's attention. I've responded to him separately on another post.

As I indicated to him, I'm really interested in free space problems, specifically, modeling a lighting discharge, for which there are no outer boundaries. The specific problem that has to be solved is the free space 3-D Poisson's equation, for which there are no outer boundaries. Of course, one has to establish a computational domain, but one would like the solution within that domain to be the free space solution. One of the standard ways of doing this using FD modeling is in two steps: (1) First, solve Poisson's equation using the integral form for the potential on the boundaries, and then (2) with the BVs so derived, solve the Dirichlet BV problem, typically with SOR methods. Presumably this same procedure could be carried out in Comsol, although I haven't yet tried it. (I'm still on training wheels, as you probably noticed.)

The more general question is, though, how to solve PDEs with BCs that are specified elsewhere than on the actual outer boundaries. One question I had is whether it is possible to programatically create and destroy boundaries that may be embedded at arbitrary locations in the computational domain, and which could then be pressed into service to solve problems.

Hi

As a quick reply, I would say that working on the interiour boundaries is exactly what the "assembly" mode is for, the only thing is that by default COMSOL puts no assumptions on the continuity between the adjacent faces so its up to you to set the correct physics and equations.
This is OK so long there are a few of them, getting tedious if you have dozens or far more, but by using cleaverly the combine geometry you can draw complex geometries, and have only a few common "assembly" boundaries, while you remain with many "continuous" by default interiour boundaries in your construction, where this is OK.

Thaks for coming with this example, it has allowed me to learn a couple of things, that really is only showing up when you start really simple (that is why I like the forum, by decomposing the issues of the other to very simple cases you learn quite a lot yourself, that is also why I'm "hooked" on the forum). I notice for my own problems, at work, I have no time and (want to) go directly to the results, sometimes cutting too quickly through the bushes ;)

Have fun with COMSOL, I'm really enjoying doing physics again

Ivar

Hi,

Free space problems are very common to COMSOL users (especially in electromagnetics, heat transfer hydrology, to name just a few). We have implemented powerful tools to cope witch such situtations efficiently:

1) Infinite elements: If you have for instant a 2D Poisson eq. on a circle of radius R you would add an ring outside of R. The inifinte elements map the region between [R, R+dR] to [R, infinity]. The resulting solutions are highly accurate as you can check with samples.
www.comsol.com/showroom/documentation/model/1412/

2) Reduced potential formulation: The fundamental solution of a poissons equation is well known, i.e. we know the analytical solution V(k) in a homogeneous space say of conductivity k. Now, if we want to know the solution for an inhomogeneous space with conductivity k+dk only the inhomogeneities will contribute. The equation can be solved for the disturbance only. For the distrubed potential we can conventionally assume that it is zero at infinity (Dirichlet conditions) but can also set more exotic ones.
www.comsol.com/shared/downloads/products/new_feature_highlights.pdf

Both concepts are provided (including tutorials) in the COMSOL ACDC Module and 1) is provided also in the Heat Transfer Module and the Earth Science Module. Although you might try to re-implement such tools starting from the equation base modes, most people interested in efficiently solvoing their problem will propbably not do so.

To answer the general question:

"Is it possible to programatically create and destroy boundaries that may be embedded at arbitrary locations in the computational domain, and which could then be pressed into service to solve problems."

Yes - you have reading and e.g. integrating access on internal boundaries. Furthermore you can also acrivate internal boundaries to have different settings than the typical continuity. Moreover - as Ivar has pointed out - you can also use the assembly concept to set non-classical discontinuous boundary conditions.
However - to solve the above problem of infinite domains, all this is not necessary. I highly recommend 1) and 2).

Sven

Hi

As a quick reply, I would say that working on the interiour boundaries is exactly what the "assembly" mode is for, the only thing is that by default COMSOL puts no assumptions on the continuity between the adjacent faces so its up to you to set the correct physics and equations.
This is OK so long there are a few of them, getting tedious if you have dozens or far more, but by using cleaverly the combine geometry you can draw complex geometries, and have only a few common "assembly" boundaries, while you remain with many "continuous" by default interiour boundaries in your construction, where this is OK.

Thaks for coming with this example, it has allowed me to learn a couple of things, that really is only showing up when you start really simple (that is why I like the forum, by decomposing the issues of the other to very simple cases you learn quite a lot yourself, that is also why I'm "hooked" on the forum). I notice for my own problems, at work, I have no time and (want to) go directly to the results, sometimes cutting too quickly through the bushes ;)

Have fun with COMSOL, I'm really enjoying doing physics again

Ivar

Thanks Ivar. I'm learning a lot, but can now see that I need to spend some more time with the documentation. I hadn't considered the assembly modes. Thanks again.

Thanks very much Sven. You and Ivar and Jean have given me enough to keep me busy for a while. I appreciate very much your patiently responding to questions that must no doubt seem trivial to you, but they were very helpful to getting me pointed in the right direction. Thanks again. Dave

Hi Davis

I would say again thanks for the question, there are no "simple/trivial" questions, I learned also a lot with this one.

I'm now still fighting how to present simply the LM's and different weak terms contributions on a simple 1D second order diff-equation (thermal Fourier law is a good starting point to have the physicsal link), one should alws start simple, but who hase time ?
I notice that we use so many implicit assumptions on functi, mostly we forget them too, and different ones if we are thinking math or physics.

By the way I have seen that COMSOL is changing the way to access the Langrange multipliers in V4, I understand they are not removing any functionality, just trying to improve the logic. I was very sceptical going to the conference last fall, but once haing been explained the new approach/methodology, I ended up finding it much clearer, even if it demanded me to turn somewhat up sidedown what I had learned myself so far.

Have nice day
Ivar

I agree 100% with you Ivar.
As for the weak term I have recently spent a significant amount of [ unbilled :-)] hours testing various example in 1d so if you have something written and want a fresh eye feel free to throw it at me. I have the same mindset as you in finding valuable for myself to look at other people problems..

and I now I will come back soon with question of my own :-)

JF

About the free space solution of Poisson's equation in 2-D:

I found an elegant solution that uses integration coupling variables
and does not require auxiliary surfaces.

The basic idea is to use coupling variables to map the solution to
the boundaries, using the Green's function kernel and the dest()
operator, and then use these to specify the Dirichlet
BC. The specific form of the integration coupling expression is:
rho*log(sqrt((x-dest(x))^2 + (y-dest(y))^2))/2/pi, which
is the kernal of the Green's function. The 2Pi factor is very
important. These are mapped to each of the surfaces in the
geometry.

Attached is a model created in 3.5a showing the solution for
a point source inside a square, with a number of holes inside
the domain and a notch out of the corner. The equipotential
contours are circular about the source, as they should be.

The "point" source here is actually a very small square, so the
integration is domain-to-boundary, and this is how it would be
used in an actual application with distributed charge. But an
illustrative example could also be set up using an actual point,
for which the coupling would be point-to-boundary integration,
instead of a domain-to-boundary as has been done here.

The basic idea should be extendable to 3-D, with appropriate
modification of the Green's function kernel.

The above model for the free space solution to the 2-D Poisson
equation needs to be checked. Although the solution has the
correct azimuthal symmetry about the point source, the actual
boundary values don't match the adjacent domain values. Also,
the asymptotic solution should have behavior for |abs(u)|
(the electric field magnitude) that goes as 1/r, which it does
not appear to have. Any help from anyone to explain this
would be greatly appreciated.

Thanks,
Dave

Correction to the above post:

"..the asymptotic solution should have behavior for |abs(u)|
(the electric field magnitude) that goes as 1/r..."

should read

"...the asymptotic solution should have behavior for |ux|
(the electric field magnitude) that goes as 1/r as measured
radially away from the point source..."

{Note to self: pause before posting...)

It SHOULD read "...behavior for |grad(u)|..."

My apologies for the confusion.

(Addendum - now testing the edit function...Thanks Sven.)

Hi Dave

A note for everyone here: pls do not abuse with "private messages" as us others cannot follow.

And have you noticed, that your "simple question" has rapidly become the longest thread on the forum !

As I have always been told, there is no simple question, and the simpler the more replies ;)

Have a nice day
Ivar

Hi Ivar,

Thanks for the tip. I haven't used the private message, but will keep
your advice in mind.

I've been busy with the simple question, and have learned a lot by
just setting up small examples. A couple things of possible interest
to others.

1. The free space solution to the 2-D Poisson's equation using
coupling variables seems to hold up (I had to iron out some sign
questions, but otherwise it works.) I assume this technique, which
uses the Green's function, is commonly known.

2. Getting the definition of the unit normal vector on boundaries
required just experimenting. The rule is, the unit normal vector is outward
away from a domain on the boundaries, as you indicated previously.
But it's different for an internal boundary INSIDE a domain. Here,
it depends on the direction of the arc or line segment. Basically,
each line segment, whether it is of a simple line or as part of a
2-D shape such as a square or circle, is drawn from, say, A to B.
"Up" is defined to be toward the left side of this segment, and
"down" toward the other side. This means that a circle, say,
has half of its unit vectors along its boundaries pointing outward
and half inward. You can see all this in action by turning on the
boundary vector display in post processing mode. It is apparently
this behavior that necessitates some of the complexities in coding
weak terms involving boundaries, especially the domain ultra weak
(bd.weak) terms. Understanding these has helped resolve some
of the mysteries of the coding of the upwinding scheme.

Let me pose another question. Instead of using the integration
coupling variables to solve the free space Poisson's problem,
is it possible to solve it by requiring the gradient along the boundary
be the same as in the next immediate inward group of cells, which
would be accesses using he up() or down() functions?

Hi all,

Just a short note (I'm really sorry, I didn't read through the whole thread)...

Thanks Ivar for your comment. What I haven't been able to find anywhere
is a good tutorial discussion with diagrams that show PRECISELY the relationship
between such things as, but not limited to, normal vectors and the underlying cells,
and diagrams to supplement the words on the definitions of "up" and "down", etc.

...but I from time to time return back to the documents (Reference Manual) of early FEMLAB versions, even 2.x, which, in my opinion, have nice and detailed documents, even examples, of how the "matrices fly" inside the COMS... I mean... the old computation engine. Of course, these are officially obsolete, but at least they've helped me get some picture of a few rather detailed problems I've sometimes wondered about COMSOL. Naturally all specifics aren't covered as features have expanded and naturally caution must be taken... but it helps you get a picture, is what I'm saying.

If you can get your hands on some, I recommend you to have a look. Imo, it's a shame the newer versions of COMSOL don't have such "Reference Manuals".

Thanks,
Antti

Dear Antti,

Many thanks for the tip! If fact, I do have an earlier set of FEMLAB 2.x manuals. One of the complaints I, too, have had is that the new version of Comsol does not ship with a hard copy of the Reference Manual. Also, their Help function needs to be updated with something better than just a set of pdf or html files. Something along the lines of the Matlab Help function would be great.

Beyond these, there is also a need for a set of structured tutorials that focus on elementary concepts. They don't necessarily have to correspond to any particular "real world" example, but instead focus on a single concept at a time. The Model files included with the software are great and work spectacularly as advertised, but many of them are too complicated to be of much use when trying to learn how things work. There are too many things going on at once - change a parameter setting and nothing works any more, and we're left without a clue as to why. It's a matter of pedagogy. Start simple, and then work up from there.

Another thing that is desirable is better error reporting, with error messages that give some indication about where the source of the error might be in the model, and reporting something more widely understandable than the somewhat cryptic traceback strings.

Thanks,
Dave

Dear all

I can only say: pls take it up with the local Comsol people when they passes by, (and I see that is for tomorrow and thursday for the real north of the US ;)
I have noticed that Comsol is still a "small" company with reactive people, so long we explain to them what we need and that we are clearly understood. On the other side they must balance the number of request versus their total user group, so the more we are with constructive suggestions if possible similar, the more we will get back ;

So pls play the game ...

Have fun Comsoling
Ivar

...
I can only say: pls take it up with the local Comsol people when they passes by, (and I see that is for tomorrow and thursday for the real north of the US ;)
...

Yes, the regional (Palo Alto for Alaska) Comsol rep is conducting a workshop here on campus tomorrow. There are quite a large number of people (>25) who have signed up for it, not bad for such an out of the way place, eh? VERY excited about this!

Hi
then catch Duncan, and Niklas if he is there, and discuss it thoroughfully
Ivar