| Author | Message | ||
     Jared Barber (jared_barber) New member Username: jared_barber Post Number: 1 Registered: 01-2007 |
Hello, I am running FlexPDE3 currently because while my advisor has both FlexPDE3 and FlexPDE5 professional versions, FlexPDE3 usually produces much quicker (while still being qualitatively acceptable) results. The code that we run involves two boundaries which are very close to each other. One can imagine a circle being one boundary, and a larger circle (or arc if you'd like) being the other. They come within .002 units of each other. While this situation is usually handled well by FlexPDE3, every now and then it throws up two different errors. Sometimes it complains of "Inconsistent Boundary ID at (5.96,-1.67)". Other times it complains that there was a "Bad Boundary Node Insert". (If need be I can put more of the error message up, I have abbreviated them for now.) I know that asking for a greater grid refinement (e.g. setting ngrid = 120 was necessary once to achieve good results) seems to get rid of the latter error. I also know that putting a limit on how close our two boundaries get to each other helps the first error (though does not completely get rid of it as of yet). The question is, what is happening with each error? Is there some way to make FlexPDE3 not encounter both errors? Maybe I should try to tell FlexPDE3 to refine more around the edges of the boundary (using "MeshSpacing" I believe) to get rid of "Bad Boundary etc."? Maybe I should limit the distance between my two boundaries even more (though physically, the two boundaries should be able to get asymptotically close)? Does FlexPDE5 have this problem as well? As using FlexPDE5 rather than FlexPDE3 will turn approximately 5 days of computation into about 20 days, you can see why we want to avoid it. (Of course, one can always change the errlim to be very large, but we're not ready to try that solution as of yet.) Also, I suppose I could tack on one more question. Is there any such thing as FlexPDE for parallel computers (e.g. in a Beowulf cluster)? Thanks to anyone who makes a dent in these questions. Jared Barber | ||
| Robert G. Nelson (rgnelson) Moderator Username: rgnelson Post Number: 727 Registered: 06-2003 |
FlexPDE version 3 was not very smart about constructing 3D meshes. The 2D base plane figure was merely projected into the Z dimension and broken into NGRID number of cells vertically. In cases like yours, with tiny cells in the base plane ring, the 3D cells would be long and needle-like. This made a relatively small mesh and fairly quick running, but did not give very good resolution of the figure in the Z dimension. Version 4 and 5 revised the 3D mesh generation to a full 3D process. The sidewalls of your cylindrical shell are gridded with triangles of roughly equilateral shape, and the triangles are then linked across the shell to form tetrahedra. This creates a mesh with many more cells, but better spatial resolution of the solution. I am not sure what the exact cause of the version 3 failure is, but you might improve things by adding a lot of fictitious layers in the Z dimension, to force better subdivision of the mesh. If you send me the script, I will try to determine the exact cause. You might also get some improvement in the version 5 speed if you scale the Z dimension to appear shorter, so that the cells that FlexPDE thinks are equilateral in scaled space are really elongated in real space. This recovers some of the version 3 character of the mesh, but with better control. See "Technical Notes | Coordinate Scaling" in the version 5 Help. FlexPDE version 6 (under development) will be fully multi-threaded to take advantage of dual and quad-processor machines. This model still requires shared-memory processors, and will not work on clusters. We will address clusters at a later date. | ||
| Jared Barber (jared_barber) New member Username: jared_barber Post Number: 2 Registered: 01-2007 |
Hello, I thought I should comment that there is no 3d involved here (rather a circle, not a sphere or a cylinder, approaching an arc). We are performing multiple 2-d computations (each of which take maybe only 1-3 mins., but there are tons of them to do). I was hoping someone else had encountered these errors before I and that could have provided me with insight. I imagined you would ask for the code. It contains multiple lines (in the neighborhood of 1000 if you count the multiple include files we use). I will instead try to make you a simpler situation which reproduces the problems I've encountered. If I have difficulties doing that, I will discuss with my advisor how to simplify our current code and make it more transparent for you. Thank you for your time so far. It is good to hear progress is being made on parallel processing. That will prove useful for us. Jared |