On Aug 26, 2013, at 5:35 PM, John Assael <[email protected]> wrote: > For example my smallest dimension in the mesh is a circle with diameter 6μ > (E-06). (where in order to get good results I have to define cellsizes of > 1E-07)
I am completely confused. Previously you said that your 1 cm x 2 cm mesh was "very small". Now you're saying that you want to resolve that mesh with 100 nm cells, so your mesh sounds very big to me. If you are defining your entire .geo file with a resolution of 1e-7 m, FiPy will need about 4 TB of memory based on recent benchmarking. We need desperately to improve that, but I don't expect ten billion cells to ever be practical. If you are defining your .geo file with 1e-7 at some locations and 1e-3 elsewhere, then I would say I have not seen Gmsh do a very good job with such big jumps in scale between neighboring geometric points. As I said before, what I recommend is that you use the "background=" argument to iteratively refine your mesh based on an appropriate error metric for your problem. All said, though, I find that Gmsh is not very good with huge changes in scale. I have some experimental code that uses libMesh to successively bisect or merge cells with high or low error. The performance seems much better than Gmsh, but my FiPy-libMesh interface is not ready for release, yet. > Now about the Gmsh2D I use a .msh generated file and import it do you think > it would be better to do it this way? I don't understand what you mean. _______________________________________________ fipy mailing list [email protected] http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
