| Author | Message | ||||
     Gasper Vindisar (gvindisa) Member Username: gvindisa Post Number: 4 Registered: 12-2004 |
Dear Sir! I've modeled heat and mass transfer with coupled PDEs. First I studied a simple brick block, sank in water with bottom side, later on I included a heat source in the brick. 2D model produces good results both with and without heat source. Problems occur when extending model to 3D. After some time the error: ‘Argument of EXP is too large (4.78666e+011). Maximum allowed is 630.776.’ is reported. I used same set of equations, same boundary conditions and material characteristics. When trying to include a heat source I had to change geometry (much smaller piece) in order to not exceed limited number of nodes (I suppose this must the consequence that I’m using a student version). Again same error occurs only this time with a different value of EXP argument. Confusing error occurs when trying to run 2D problem in longer time period! If errlim is set to 1e-4 it’s said that timestep has fallen below 1e-009 of start value. If errlim is only 1e-1 again argument EXP is too large. What would be recommended changes of scripts in order to avoid above stated problems? Thank you, Gasper Vindisar
| ||||
| Robert G. Nelson (rgnelson) Moderator Username: rgnelson Post Number: 319 Registered: 06-2003 |
Several observations: 1. You should always use Monitors to get feedback about how the solution is progressing, and most especially when you are first developing the script. In a time-dependent problem, you should monitor all variables with contour plots at cycle-based intervals, so that no matter what the timestep control does, you will always see some kind of report. Use the plot-time control "FOR CYCLE=10" to control the plot group. 2. If you do this, you will see that your discontinuous initial conditions on Temp and W cause FlexPDE to allocate all available nodes (which are in limited supply in the student version) at the bottom boundary, leaving no cells free to resolve the input wave coming from the right wall. Your use of ERRLIM=1e-4 has made the problem worse, because it forces even denser meshing at the bottom boundary. Take out the ERRLIM and NGRID controls, and instead put MESH_SPACING controls along the input boundaries to concentrate the available mesh where the action is. 3. The Finite Element method uses polynomial approximations within each mesh cell to model the solution. Discontinuities and steep fronts cannot be modeled with piecewise polynomials, so there is some over- and under-shoot resolving the discontinuous distribution of w. As a result, some of the trial values of w are negative. This interacts with your nonlinear expressions for D_T and D_W to produce unrealistic values. Put a floor on the value of W used in these computations to guarantee that the diffusivities stay in a reasonable range. 4. Both of your equations are diffusion equations. If the diffusivity in these equations ever goes negative, the equations become explosive and quickly exceed the limits of numeric representation of the hardware. I believe this is what is happening in your problem. Inadequate mesh density (limited by the student version) causes undershoots in W which eventually cause negative diffusivities and subsequent crash. 5. One way to address the problems inherent in modeling discontinuities is to initialize your problem with already smoothed initial conditions. Instead of an initial value of W0 everywhere and W1 as a bottom boundary value, initialize to W0+(W1-W0)*exp(-(y/y0)), where y0 is an arbitrary smearing width. This eases the difficulty of modeling the solution with quadratic pieces. The attached modification of your problem addresses these issues and runs smoothly to completion with version 4.2.8. This version uses "PREFER_STABILITY" by default, and you may need to set this selector manually on earlier versions of FlexPDE.
| ||||
| Gasper Vindisar (gvindisa) Member Username: gvindisa Post Number: 5 Registered: 12-2004 |
Dear Sir! I thank you for your valuable suggestions. I ran both versions of scripts. Still errors occur at both. Max simulation time while running ‘old’ version is 31 days, while improved version reports error already at 19 days. Errors are about time step. Do you believe any further improvements could be done in order to prolong time period of simulation or is it all about a student version I’m using (v. 4.2.3)? My goal is to make simulations of at least one year (4 seasons) and with nonconstant boundary conditions. Thank you, Gasper Vindisar
| ||||
| Robert G. Nelson (rgnelson) Moderator Username: rgnelson Post Number: 322 Registered: 06-2003 |
I ran "HAM2d" to 31 days, and "Improved" to 365 days on student version 4.2.3 without sign of trouble. See attached plot. You'll have to provide more information about what kind of a failure you experienced, because I can't reproduce it. It was necessary to specify a small initial timestep (1e-7) to avoid the "safety net" stop on small timestep at the beginning. Lacking other information, FlexPDE attempts to start the calculation with a timestep of 1e-4 times the total run time. The adaptive control then modifies this value until a clean startup is achieved. If the modified timestep is less than 1e-9 times the initial attempt (ie, 1e-13 times the total run length), FlexPDE assumes that something is wrong and stops. In a problem like yours, with a very long total run and steep initial fronts, you must inform FlexPDE that the initial step must be small. So make your TIME section say something like TIME FROM 0 TO 365*seconds_per_year BY 1e-7  |
HAM2D.pde