[Getdp] GetDP: a problem about init and show surface values /// Transient temperature calculations
michael.asam at infineon.com
michael.asam at infineon.com
Wed Jun 1 14:36:34 CEST 2011
Hi,
there are two things you have to correct in your BOX.pro file:
1) It's necessary to have your surfaces also in the function space.
2) In the postprocessing you have the quantity T twice. Just use one definition
with a region containing both, volumes and surfaces.
Please find attached the corrected file.
I hope it helps.
Hi Joakim,
yes, GetDP can handle this kind of simulation you want.
Please have a look at the files from daiweifengfudan at gmail.com and this one here.
Implementing time varying boundary conditions is quite easy and is explained
in the documentation.
Examples of coupled simulations are shown in the Wiki:
https://geuz.org/trac/getdp
Kind regards,
Michael
-----Original Message-----
From: getdp-bounces at ace20.montefiore.ulg.ac.be [mailto:getdp-bounces at ace20.montefiore.ulg.ac.be] On Behalf Of getdp-request at ace20.montefiore.ulg.ac.be
Sent: Wednesday, June 01, 2011 11:45 AM
To: getdp at geuz.org
Subject: getdp Digest, Vol 99, Issue 1
Send getdp mailing list submissions to
getdp at geuz.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.geuz.org/mailman/listinfo/getdp
or, via email, send a message with subject or body 'help' to
getdp-request at geuz.org
You can reach the person managing the list at
getdp-owner at geuz.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of getdp digest..."
Today's Topics:
1. Re: Floating potentials in 3D: long execution times (John_V)
2. Transient temperature calculations (Joakim Sandstr?m)
3. GetDP: a problem about init and show surface values (???)
----------------------------------------------------------------------
Message: 1
Date: Tue, 31 May 2011 15:08:20 -0400
From: John_V <jvillar.john at gmail.com>
To: getdp at geuz.org
Cc: Christophe Geuzaine <cgeuzaine at ulg.ac.be>
Subject: Re: [Getdp] Floating potentials in 3D: long execution times
Message-ID: <BANLkTinZe56QO5Pww_=oQNW1vYtSHM0oYg at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I'm confirming that the fix worked. What had required 57 minutes now takes
only a bit over 3.5.
Thanks very much!
--John
On Sat, May 28, 2011 at 10:19 AM, Christophe Geuzaine
<cgeuzaine at ulg.ac.be>wrote:
>
> To the list: these performance issues should be fixed in SVN. If you use
> global quantities please le us know if you encounter any problems with the
> new version.
>
>
>
>
> On 27/05/11 08:33, Christophe Geuzaine wrote:
>
>>
>> Hi John - Thanks for the feedback. The two issues you mention (slow
>> generation of GroupsOfNodesOf and slow assembly) are indeed known, but
>> seem to be especially bad in your case. How many nodes do you have on
>> the floating potential surfaces?
>>
>>
>> On 25/05/11 17:54, John_V wrote:
>>
>>> I am using GetDP to calculate the potential in a 3D geometry of mixed
>>> conductors and insulators. The calculation is repeated frequently with
>>> different charge distributions, so CPU time is important. Even though my
>>> mesh has ~400k nodes, with some experimenting I have been able to get
>>> good solutions in about 90 seconds, provided all the conducting surfaces
>>> have Dirichlet boundary conditions.
>>>
>>> I need also to be able to deal with floating conductors, however. My
>>> first attempt at this was to treat the floating conductor as if it were
>>> a dielectric with very large dielectric constant. The problem with this
>>> approach is that it degrades the condition of the matrix. I have to use
>>> the ILUP preconditioner (~12 minutes to compute) instead of the faster
>>> ILU0 one (0.3 seconds).
>>>
>>> The discussion of floating potentials in the manual gave me hope of a
>>> better alternative. Bernhard Kubicek's "Capacitor2D" example on the Wiki
>>> showed the way, The method is very elegant, based I think on basis
>>> functions for groups of nodes as described in the paper by Dular,
>>> Legros, and Nicolet in IEEE Trans. Magnet. 34 (1998). I have implemented
>>> this for my 3D geometry.
>>>
>>> As I hoped, doing it this way let me return to the fast ILU0
>>> precondition. However, time gained here is lost elsewhere. Execution
>>> times are VERY large. It requires a total of 57 minutes CPU time for
>>> this method on my mesh.
>>>
>>> The two largest contributors to the 57 minutes are preprocessing
>>> (especially generating GroupsOfNodesOf, 27.5 minutes) and generating the
>>> system of equations (29 minutes).
>>>
>>> What is GetDP doing during all that time? Are these operations
>>> inherently this time-consuming?
>>>
>>> John
>>>
>>>
>>>
>>> _______________________________________________
>>> getdp mailing list
>>> getdp at geuz.org
>>> http://www.geuz.org/mailman/listinfo/getdp
>>>
>>
>>
>>
>
> --
> Prof. Christophe Geuzaine
> University of Liege, Electrical Engineering and Computer Science
> http://www.montefiore.ulg.ac.be/~geuzaine
>
> _______________________________________________
> getdp mailing list
> getdp at geuz.org
> http://www.geuz.org/mailman/listinfo/getdp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.geuz.org/pipermail/getdp/attachments/20110531/af826ac6/attachment-0001.htm>
------------------------------
Message: 2
Date: Tue, 31 May 2011 12:36:18 +0200
From: Joakim Sandstr?m <joakim.sandstrom at brandskyddslaget.se>
To: "getdp at geuz.org" <getdp at geuz.org>
Subject: [Getdp] Transient temperature calculations
Message-ID:
<C91E91102A1FCE478BBECB897E89382B47E75077 at BSLSTO2.BSL.local>
Content-Type: text/plain; charset="iso-8859-1"
Is there a possibility to use getDP for thermal and mechanical calculations based on a specified, transient temperature boundary? Two main issues:
* The boundary flux into the model is specified with q = epsilon * sigma * (Text^4 - Tbound^4) + h * (Text - Tbound) where Tbound is the surface temperature of the object and Text is the surrounding temperature heating the object. Text changes over time and can be expressed with an equation or time - temperature pairs.
* The material properties are temperature dependent, both for the thermal calculations and the mechanical calculations.
If there is a possibility to implement some form of radiative exchange model for internal surfaces inside objects that would be a great advantage too.
Is this possible within the existing code, possible to do with minor changes or do I need to look elsewhere?
Joakim Sandstr?m
Doktorand brandteknik LTU, Civilingenj?r brandteknik, Brandingenj?r
________________________________
Brandskyddslaget AB
Kungsgatan 12, Box 187, 651 05 Karlstad
Telefon: 054-777 74 70 | Direkt: 054-777 74 72 | Mobil: 0706-21 55 81
E-post: joakim.sandstrom at brandskyddslaget.se | Hemsida: brandskyddslaget.se
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.geuz.org/pipermail/getdp/attachments/20110531/f174a9dd/attachment.htm>
------------------------------
Message: 3
Date: Wed, 1 Jun 2011 14:09:38 +0800
From: ??? <daiweifengfudan at gmail.com>
To: getdp at geuz.org
Subject: [Getdp] GetDP: a problem about init and show surface values
Message-ID: <BANLkTi=zEQqMhTWyNgigVH=mEi2FyLU4rw at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I have a problem about getdp:
I use the thermal static/transient equations and choose some boundary
conditions for my simple box model.
But I find:
(1) Static problem: Assign T0 on top and assign T1 on bottom (Surface). But
in the post-processing views, I cannot see the surface value (all equal to
zero!). However the calculation is OK because the volume value is shown
rightly.
(2) Maybe the same reason to (1). In transient problem: If I set a initial
value on the volume (and surfaces), I will find that the surface radiation
boundary condition doesn't work and surface values equal to zero, too!
My model and project files are attached here.
Thank you very much !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.geuz.org/pipermail/getdp/attachments/20110601/623daa2c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SimpleTest.tar.gz
Type: application/x-gzip
Size: 905403 bytes
Desc: not available
URL: <http://www.geuz.org/pipermail/getdp/attachments/20110601/623daa2c/attachment.gz>
------------------------------
_______________________________________________
getdp mailing list
getdp at geuz.org
http://www.geuz.org/mailman/listinfo/getdp
End of getdp Digest, Vol 99, Issue 1
************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BOX.pro
Type: application/octet-stream
Size: 6131 bytes
Desc: BOX.pro
URL: <http://www.geuz.org/pipermail/getdp/attachments/20110601/ee907593/attachment.pro>