Moving boundary conditions in welding... Log Out | Topics | Search
Moderators | Register | Edit Profile

FlexPDE User's Forum » User Postings » Moving boundary conditions in welding simulation « Previous Next »

Author Message
Top of pagePrevious messageNext messageBottom of page Link to this message

Carlos Tais (tais_c)
New member
Username: tais_c

Post Number: 1
Registered: 07-2005
Posted on Friday, July 22, 2005 - 08:58 am:   

Hi, I'm using flexpde 5.03 for simulation welding processes, but I need to use moving boundary conditions for modeling the heat flow in the weld path. Can I do this in FlexPde? If yes, How can implemment it?.
Thank you very much in advance

Carlos
Top of pagePrevious messageNext messageBottom of page Link to this message

Robert G. Nelson (rgnelson)
Moderator
Username: rgnelson

Post Number: 411
Registered: 06-2003
Posted on Friday, July 22, 2005 - 08:45 pm:   

See "Moving Meshes" in the Help Index and the example problems in the "Samples | Moving_Mesh" folder.
Top of pagePrevious messageNext messageBottom of page Link to this message

Carlos Tais (tais_c)
New member
Username: tais_c

Post Number: 2
Registered: 07-2005
Posted on Saturday, July 23, 2005 - 09:06 am:   

Thank you very much
Top of pagePrevious messageNext messageBottom of page Link to this message

Poletaev (nick)
New member
Username: nick

Post Number: 1
Registered: 11-2005
Posted on Sunday, November 06, 2005 - 05:38 pm:   

I want to use PDE for simulation of the processes with moving boundaries (Stephan's problem). Can I any way to use domain boundary condition :velocity (sur_coord) =- D*grad(C), where grad(C) is a term of my differential equation? My script (see attach) cannot to solve this problem (Memory protect falt error).Can I do this in FlexPde?
Thank you very much in advance
application/octet-streamMove_Mesh.pde
Move_Mesh.pde (1.0 k)
Top of pagePrevious messageNext messageBottom of page Link to this message

Robert G. Nelson (rgnelson)
Moderator
Username: rgnelson

Post Number: 490
Registered: 06-2003
Posted on Monday, November 07, 2005 - 04:17 pm:   

I'm not sure I understand the point of moving the mesh in this problem, but nevertheless, the error is not related to moving meshes. If you remove the rv variable and its boundary conditions, you still get into trouble just solving for vel.

The first difficulty is that you have incompatible initial conditions on vel. You don't declare an initial value, so the default is zero. But you have an interior value BC on vel that is nonzero. This means that at time zero, the value of vel jumps instantaneously from zero to some nonzero value. This requires a zero timestep, since "instantaneous" means "occuring in zero time". Specify an initial value for vel consistent with the internal boundary condition. Don't use "normal" to do this, because other than on the boundary point, "normal" is undefined.

You can proceed to debug this script from this point, merely trying to solve for vel, without rv or moving meshes.
Add plots of all variables and all terms of the equations, using a plot time selector "FOR CYCLE=1". This gives you information right up to the time of halting.
Top of pagePrevious messageNext messageBottom of page Link to this message

Poletaev (nick)
New member
Username: nick

Post Number: 2
Registered: 11-2005
Posted on Tuesday, November 08, 2005 - 08:05 am:   

Thank you very mush for your message. For any initial conditions on vel (script Move_Mesh.pde) I can't specify any expressions for vel (e.g. value(vel)=expression) in boundary section, if expression contains problem dependent variables. Such specifications always caurse ‘Memory protection fault’ error. What I do incorrectly? Can you give example of the moving mesh if ‘vel’ are function of the problem dependent variables?

Thank you very much
Poletaev
Top of pagePrevious messageNext messageBottom of page Link to this message

Robert G. Nelson (rgnelson)
Moderator
Username: rgnelson

Post Number: 491
Registered: 06-2003
Posted on Tuesday, November 08, 2005 - 07:06 pm:   

Here is a version of your file that runs and computes "vel", but does not move the mesh (I'm still not sure what you hope to gain by moving the mesh...).

I have done several things to your script:

1) as pointed out in a previous posting, you have an inconsistency between the initial value of "vel" and the interior value boundary condition. I have added an initial value for "vel" that is consistent with that BC. (I don't understand your remark about failure to declare an initial value in the boundaries section. You don't declare initial values in the Boundaries section; you declare them in the Initial Values section...)

2) you have a similar inconsistency between initial value and boundary condition on "CFuel". You have used a SWAGE initial condition around r=rdr0, which means that the initial value at r=rdr0 will be 1/2 (middle of the smoothed transition). Your interior value BC on CFuel forces the value 1 at this point, so the initial value and BC are in conflict.

3) you have specified a Halt when the value of CFuel at the sphere center drops below 0.95. But this will never happen, because you have specified a value BC of 1 forever at r=rdr0. Because of this and item 2, I have removed the CFuel=1 interior boundary condition.

4) You have specified an end time of 30, but everything is over by 0.003, so I have changed the end time.

5) You have specified an initial timestep of 0.001, but since the whole process is over by 0.003, this is much too large. Take out the initial timestep specification and let FlexPDE figure it out.

6) Since the initial droplet is only 1/50 of the total domain size, the default mesh (ngrid=100) puts only two cells in the droplet. The default initial smoothing then smears the distribution substantially. You should request a denser mesh in the small droplet. You can use a large NGRID, or specify MESH_SPACING in the droplet, as I have done.

7) You have specified VALUE(vel)=normal(flux) on the interior boundary, but NORMAL has a different sign on the two sides of the boundary. It is safer to use an unambiguous VALUE(vel)=-D*dr(CFuel).

8) You have specified no boundary condition for "vel" at the sphere center, which means NATURAL(vel)=0, which in turn means r^2*dr(vel)= 0*dr(vel)=0, which is no condition at all. I have used VALUE(vel)=0 at the sphere center.

9) I have added a lot of plots, to see what is going on. (I made them PLOTS instead of MONITORS, so I could look at them after the run).

-----
Having done all these things, we finally come to something real:

There appears to be an error in way FlexPDE handles upwind alalysis of the r^2 factors in the spherical divergence operator.
To avoid these errors, you need to specify
SELECT UPWIND=OFF.

application/octet-stream
Move_Mesh1.pde (1.4 k)
Top of pagePrevious messageNext messageBottom of page Link to this message

Poletaev (nick)
Junior Member
Username: nick

Post Number: 3
Registered: 11-2005
Posted on Thursday, November 10, 2005 - 07:44 am:   

Dear Robert G. Nelson,
as a result you had got another problem - smoothing of the initial distribution of the dependent variable CFuel with time. In your version of my script variable “vel” defines nothing and may be removed from script.
My problem is - vaporization of a boiling liquid droplet (region 2 in script) into gas atmosphere (region 1):

dt(Cfuel)=(1/r^2)*dr(r^2*D*dr(Cfuel))
dt(rs)=(-D*dr(Cfuel)) on droplet surface,

where rs is a radius of a liquid droplet, which become smaller and smaller as a result of vaporization: from initial value (rs=rdr0) to zero (in other words – the external boundary region 2 changes its value from rdr0 to 0). Radius rs reduces with velocity (dt(rs) ) which is defined by diffusion flux of vapor on the droplet surface. Study of the velocity of the droplet vaporization is one of the main goals in my problem. For solving such problem we have to use the moving mesh. In this case the velocity of moving mesh will define the droplet vaporization rate.
Thank you very much
Poletaev
Top of pagePrevious messageNext messageBottom of page Link to this message

Robert G. Nelson (rgnelson)
Moderator
Username: rgnelson

Post Number: 492
Registered: 06-2003
Posted on Thursday, November 10, 2005 - 04:43 pm:   

The purpose for computing "vel" without applying it to mesh motion was to validate that a stable velocity could, indeed, be calculated. This is part of the scientific method: to validate the basic operation before proceeding to the exotic. The builders of the Pyramids laid the bottom layer first. Those that began with the capstone met with failure.

If this is evaporation off a droplet, one would expect different material properties in the vapor than in the liquid. In this case, it would as you say be necessary to move the mesh. Demonstrating a stable velocity computation should allow you to do that.

Add Your Message Here
Post:
Username: Posting Information:
This is a private posting area. Only registered users and moderators may post messages here.
Password:
Options: Enable HTML code in message
Automatically activate URLs in message
Action:

Topics | Last Day | Last Week | Tree View | Search | Help/Instructions | Program Credits Administration