Discussion Forum

Hi

Well either you talk about a node, as it moves around, with or without a deformed frame, or a given "floating" point that you must interpolate the results from the adjacent nodes.

The matlab interface functions such as "postinterp"-olate are there for that, see the "command.pdf" doc

There have been a few discussion earlier on how to sort and extract data for boundaries, particularly with Matlab, that is by far the easiest and safest from my point of view. Try the "search" on the forum with keywordds auch as "group" or "bounday data" or "posrtinerp" .

Good luck
Ivar

Thank you very much!!
I had already "guessed" that I could do that with Matlab [ but youprovided me with the solution] but I am a VERY NEW Comsol user, I bought my license last month and for cash fllow management reason have to wait a few month before adding matlab...

so I guess from your answer that there is nothing I can do until then [ and yes it is a moving floating point living inside a subdomain]...

merci beaucoup encore quand meme :-)

JF

Hi

No I would not say that, you can do incredible things, just with the GUIs', but it's (feels) more tricky and is cetainly more "clicky", that's all.

In the GUI you have the "Postprocessing Cross-Section - Point tab" option to run postinterp (I believe or at least something very similar). For you you need to enter the coordinate position of your point of interest, that you must get from some global equations you set up as I understand your point si moving around independently of the mesh, this is OK with COMSOL and often used for boundary conditions that are defined by bolean expression inequalities.

You also have the line option, by the way, you can set point(s) and draw line(s) with the point and line option on the left border of your postprocessing graphics view, there are many shortcut tricks to learn, some are discussed in the forum, try a search on the forum.

Good luck
Ivar

Thanks again but it is not what I need.

My need is to couple this expression value at a moving point with other part of the model DURING the solving phase...
post processing do nothing to me there...
but I appreciate truly your input
JF

Hi again

Sorry I misread, but then you need to set a boundary condition (probably through a weak constraints) on one of the depedent variables of your model, via your external equations, and ensure a fine enough mesh so that the equation is "acting" on something, adding point constraints leads easily to singularities.

I usually "index" my PDF documentation and run some searches thereon (I preferred the Google version, but my company IT policy forces me on the MS one, that is leff effective). Try a "weak" or "boundary conditions" (but these are very generic terms try out some more specific for your application) and sort your search to the general doc and the specific application mode, or physics you are intrested in (their might be several as today each "application mode" mixes several "physics"). Usually you get excelelnt starting points therein, then you have the model library and the conference examples on the main web site

Good luck
Ivar

Thanks
I understand what you mean but I will need to increase my level of proficiency in order to implement what you are suggesting so I have some work ahead of me ...
what I will was thinking trying tough will have been to locate the closest nodes around my moving point and construct the value of my expression at the said point as an average of the value at the surrounding nodes... but I cannot see an easy way to manipulate the underlying node structure inside the model ... and through the gui....this was leading me into learning the m field structure as a possible way to manipulate this too...

but it was worth checking if there was a simpler solution unknown of me....

JF

Hi

For me, I believe you should work one level above, with COMSOL you have first of all a PDE solver, the FEM, hence the mesh, is "just" the solver way, so try to forget a moment about mesh, nodes elements, it took me some time to leave the engineering "floor" again when I started with COMSOL, and get back to basic physics, but it improves, for me, the search of solutions.

Go back to the physics, you have a geometry with its internal and external boundary condition, and you have an external equation ODE/PDE (nothing else than one more of those implemented already, and all the application modes are in fact "only" a nice assembly of predefined and pre-set up equation sets all based on the fundamental ones) that defines some particular condition in a given region (that moves OK).

Now you should separate the time dependent and the spatial dependent elemens, time is treated slightly differently, by default, in Comsol, as its ALWAYS there underlaying, its fixed and the variable is "t", while x,y,z can always be renamed. But you turn on and off the time dependency by applying the physics properties "transient" or "static" approach (and eigenmodes or harmonic are a particular development in the frequency domain of the time dependet equations).

You must now get out from your additional equations the local boundary conditions on the desired variable, and you apply it as is. Better if it applies to a region, rather a "point".

Try to dig out the example of the heating laser beam rotating along a circle, I do not know any longer if this is in a conference paper, probably its in the model gallery on the web site ... indeed: www.comsol.com/showroom/gallery/699/

there are many other examples around too, and some good boks in, have a look at
www.comsol.com/academic/books/

Good luck
Ivar

PS: Do not give up, there is a little hill to climb and probably quite some conceptual changes to do if your are an experimented FEM programmer of "older" classical FEM soft., but then the slopes behind are really nice and you will really enjoy it and not turn back

Thanks Ivar I understand what you say and will follow your advice... but this solver and black box things make me feel uincoonfortabe at a time .. let me go off to topic for your benefit...
On another piece of work I had spurious oscilation.. I did some work to find the casue and what I vfound really puzzle me... I am still working on that myself but for your benefit... do the following [ 2 min at most]

1d geometry 1 line arbitrary length
MOde stationnary pde in coefficient mode
all coeeficient 0 in the subdomain except aplha=1
boundary condition h=1 r=1 left
h=0 r= 0 right [ first order pde ]

mesh and resolve !!!
the solution should be constant =1 you will be surprised by the result
the magnitude of the oscilation is independant of the mesh size and dependant of element choice but never come colose to the solution!!
if ther are setiing that will provide the correct solution to the problem as described above they are not obvious to me [ but I am exploring this becasue i cannot use comsol if I dont understand whow to use it properly there
granted there is simpler way to resolve this equation... but this problem should not be there in the first place if we really can consider comsol as a robust solver... we should be able to calculate linear equation with constant solution dont we?

will be curious to get your opinion on this little example tough...
JF

Hi

Well for me with COMSOL there is NO BLACK BOX (in contrary to what I felt with the older FEM softwares), Comsol gives you de opportunity to see all the equations, you just need to understand their naming convention see the "ref" doc and where to look: (Physics - Equations System ...), but I agree, it took me about a year to feel compfortable, and I'm still discovering, 3 years later...

So back to your problem, indeed I assembled it quickly, andnotice that the "result" changes quite drastically withthe mesh and the higher modes, so this does not look correct, but ...

Now there is an "effect" that time to time (and obviously in 1D its more critical, I not often down there) has been fooling me: it's the postprocessing "Element refinement Auto".

If you take the "Plot Posprocessing" and deselect "Element Refinement" and choose "1" you vill get the direct node results, not interpolated results, and then, from the moment you use quadratic elements (or above) you find your result constant "1", no ?.
If you use linear you get back your "oscillation", once slope per element (and then "auto" means anyhow 1) so there are probybly some good mathematical reasons here, even if not physical ;)

In fact it gave me the reply to another user forum issue having trouble with 1D PDE, we should perhaps report this to "support", the refinement should probably better be set to "off" in 1D

Thanks for the hint, and hope this helps

Good luck
Ivar

well the important question is that when the calcualted solution [ and the real solution is on linear more complicated..] is coupled on a boundary of a 2d domain what is coupled for the calculation....??? [ I reduced a complicated convergence problem induced by oscillations to this very simple example that has no interrest on its own.. except for a benchamark verification purpose.. but for me it asks a lot of quesiton in itself..

I will keep spending some time on it anyway I tend to like to go to the bottom of the things and if I learn anyting usefull i will let you know...

JF

Hi again

If you are on the benchmarking level, then clearly you should distinguish pre - solve & post processing issues, the oscillation is clearly a postprocessing issue of your solved calculations, if you use matlab and dump out the node values, I'm 99% sure these are the same i.e. = 1 (not 100% because I will have to check first, I'm not "thomas", but still ...)

But indeed, one must undertand well the physics one is setting in the PDE's, and the mathematics how this is solved

Same for me, you gave me just an interesting hint, I'm replying to the other user, this might well be his problem too, he has been fighting fore > 1-2 months now on his 1D issue

Good luck
Ivar

Ivar this was a god idea....
but unfortunately it is the calculation NOt the post processing
I used the function export -> postprocessing data to creat t text file option save on nodes... [ I dont have matlab at the moment..]

and the ascii file gives the oscillation exactely as seen in the post processing window so for me the calculation is incorrect and the initial setting post processing render whatever has been calculated...

[ which is also compatible with the way I "found" this example becasue of convergence issue not becasue of a wong result...Indeed, I use the solution of my true 1d equation as a load for a multiphysic l 2d problem and get convergence issues. they disappear if I smooth artificially and unphysically the solution of my initial [ complicated 1d problem]....
starting from this I reduced the problem toward its simplest form described in the example I showed you...

so again this is not normal for me but given my status of Grand beginner as a comsol user I assume I an doing something wrong and try to find what it is....
happy I can be a contributor that realy in my comsol user life
.I will feel less guilty to ask more questions in the future...

JF

Hi again

I have just posted your example above, referring to this discussion to "comsol support", will see what they answers
Ivar

is there a link for your posting or did you sent it by email?
I am obviously interrested to get their response

JF

Hi
No link it was an ordinary e-mail, but I got a quick reply from Nils, he's from my knowledge one of the "mathematical fathers" behind COMSOL, it's always a pleasure to listen to him on his presentations during the conferences, I can only strongly suggest that you come to the 2010 one in Paris (there are others in the US and Asia if you are there in November).

As I have experienced before he's reply surprised me as I though I was right, but no, and sends me back to study the books again, here it is:

=====================
...
Thank you for trusting our solvers. Indeed, they are not to blame in this case. However, the oscillations are not a postprocessing issue. Rather, it is the problem itself which is ill-posed and lacks a solution. If you enter a convective flux in the alpha coefficient, the partial integration performed to put the equations on weak form give rise to a natural boundary condition corresponding to "specified normal flux".

Setting h=0, r=0 on the right-hand side is the same thing as setting the normal flux to zero - which also implies u=0! On the left-hand side, h=1,
r=1 sets both u and the inward flux to 1. In a problem with only a conservative flux, we cannot have the flux equal to 1 on one end and equal to zero on the other end. There is simply no such (continuous) solution.

The solver does the best it can and makes sure to satisfy the left-hand side condition point-wise, while at the same time satisfying the right-hand side condition on average. If you try solving with different element orders, you will see that you always get a solution oscillating with the highest frequency that can be represented on the mesh, and if you check, you will find that its integral is always zero (except for pure numerical noise).

I also checked the original thread in the COMSOL community. There is, in fact, a rather easy way for Jean Francois to do what he originally asked about. The trick is to use an Extrusion coupling variable with source on the subdomain domain and destination on a point. Use "General transformation" with the default source transformation, but a time-dependent destination transformation. This will make the extrusion coupling variable read its value from different points at different times, using interpolation on the mesh.

Note that you don't get any Jacobian (or symbolic derivative) contributions from the destination transformation expression, though. So you may need to set up derivatives manually, as separate variables, in some cases.

Best regards ...
===============

So more to study, for me too ... ;)
I'll start re-reading the modeling.pdf. and the chapter "weak form"
Have a nice day
Ivar

Thank you very much this is very clear and helpful!!

HAving say that i will make the following comment regarding my example above
from a formal point of view alpha =1 OR beta =1 [everything else being unchanged is the SAME problem] One is solved properly bu COMSOL the other not.

At this point in time [ again being cautious as a beginner] I do not see anything in the COMSOL documentation that will motivate this difference in solving procedure.
[ My personnal current understanding is that the divergence term can be used ONLY with c not null but again
have found nothing on that in the documentaiton s far...]

Merci encore !
JF

Hi again

Well I agree "alpha" and "beta" have the same behaviour except for the sign ... if you look only on the subdomain equations,
but if you check ALSO the boundary equations you have an "alpha" there too, but no "beta", and this IS different and clearly writte out !

So both describe "convection" but alpha is related to "Conservative Flux", as it appears also on the boundaries, see "quick.pdf" p80++ (V3.5a), check also modeling.pdf and Guide.pdf

or some of the older books from www.comsol.com/academic/books/
in particular www.comsol.com/academic/books/mmwfem/

the latter deal mostly with chemistry, but starts at pde level, it is based on v3.3 and the older femlab version so some of the models described need some tweaking there are a few discussions and responses on the forum (check first command.com p17++ for function obsolecence for older versions)

Have fun
Ivar

GOtcha!!
and Silly me
I had overlooked the fact that when you use the divergent term in the pde you need a compatible BC to get along !!!
this explain everything now...
my PDE skills are a little rusry I am affraid

so yur practical comment altogether with the more theoretical comments expalin what happened with my "example" [ and incidentally the way i was coding my application was wrong in the very same way too...
so I know how to recode it now.

and Thanks also for the reference i will certainly look into that and will try to attend the Paris conference if i am in france at the time [ I live only part time there...] so I dont know

merci encore !!
JF

I overlooked it too, quickly done

By the way on your next travel, or free time, have a look at the modelling.pdf chapter 17 "Stabilisation techniques" it gives also some clues on the "tricks" used to keep the solver stable.

But I'm always astonished how much new I find when I re-read these chapters, I must be at 5th or 6th re-reading, finding always new things I had overlooked ...

Have fun
Ivar

Hi Ivar,
I have seen you mentioning for many to search for command.pdf could you please tell me where can i find it?.....

thank you

Hi Ivar,
I have seen you mentioning for many to search for command.pdf could you please tell me where can i find it?.....

thank you

It is in the documentation of Comsol 3.5a (look for help menu then helpdesk)

In the new version 4.0a you should look for COMSOL40a/doc/pdf/mph/mph_ref.pdf


--
Comsol 4.0a
Ubuntu 10.04.1