Hi Wolfgang, Thank you for reply. Unfortunately, google does not allow me to attach large meshes here (file is too big? > 300MB for a 3D mesh with dofs 2.5M in .msh). Is there any other way? I would like to share it with you.
Here I attach the website of our project here, MTA <https://staffnet.cs.manchester.ac.uk/acso/thermal-analyzer/> I did not share the deal.II code in the package simply because this program needs a customized deal.ii to compile it. Therefore, I embedded all dependency in it and share it in binary. The mesh generator inside the package can create coase mesh based on defintion of structure (xml file) and do refinement. For some exaples, I do not refine it because it is already very fine. I plan to share the code in future. My friends and I implemented some time-stepper such as bdf, stable trapezoidal, etc. I believe this would help the community. I find the best way to avoid the reorder step is to create your own mesh and bypass it. I'm also working on this. If there is any progress, I'd like to share it. Thanks YC Chen On Tuesday, February 7, 2017 at 5:54:29 PM UTC, Wolfgang Bangerth wrote: > > Yi-Chung, > > > I'm willing to work on this part. Please let me know how should I start > it. I > > believe this code will help the community. > > No doubt! Thank you for your offer of help! > > I'm going to comment in more detail below, but will point out that for all > major development, it is always helpful to do it in a way so that you can > get > feedback early and often. There is nothing worse than going to work for > two or > three months, uploading all of your code, and then getting feedback that > something could have been done in a much simpler way, or should have been > done > in a different way to make it more general. In other words, whenever you > have > something that is working, put it into a github pull request and let > others > take a look and comment on it! > > > > > My application is about IC designs that > > > may have million to billion cells. A fully distributed > triangulation > > > helps to reduce memory usage. The current shared_memory system can > > > handle 20M (single core) in system of 32GB main memory. > > > > That's already quite impressive :-) What kind of meshes do you have > that > > require so many cells? Are they geometrically incredibly complicated > to > > require that many cells already at the coarse level? > > > > Actually, this is the interesting part. We try to simulate thermal > profile of > > integrated circuit. For a CPU, it has billion transistors inside and > each of > > then has its own power trace as RHS. That is why we have to give it a > large > > coarse mesh at beginning. I did some model reductions for transistors, > but I > > still want my tool can simulate 100M cells to ensure accuracy. > > That makes sense. My question was more motivated by why you need a > *coarse* > mesh that is so fine? If your geometry is relatively simple, but you need > high > resolution, then you can just take a coarse mesh with simple cells and > refine > it a sufficient number of times. That already works -- we have done > computations on 100M cells many times. > > The only reason I can see for a very fine coarse mesh is if you need to > resolve geometries with lots and lots and lots of curved edges and > corners. > > > > Yes, I'm willing to believe this. The algorithm wasn't intended for > > meshes of this size, though we did test it with ~300k cells in 2d > and we > > know that it scales like O(N). So 200 seconds seems like a long > time. Is > > this in debug mode? > > > > Unfortunately not in debug mode.I guess the reorder is more like O(N^2 > or N^4) > > if I may recall. > > Hm, that is strange. Would you be willing to share one or two of your > meshes > with one or a few million cells? If you can't share them publicly, can you > share them with me? > > > > It searches the cells will minimum numbers of neighbors and then search > again > > recursively for its neighbors. With increasing number of dofs, time > increases > > exponentially. > > Ah, I see -- that's the reordering in the Cuthill-McKee step in > parallel::distributed::Triangulation. Interesting. I wonder whether we > could > come up with a more scalable implementation of this algorithm by building > up > different data structures. > > > > In my setup program, a steady state 3-D thermal simulation (distributed > trial) > > for a problem of 5M dofs in two cores requires 200 sec reorder, 80 sec > > setup_system, 80 sec solver time (petsc-MPI). 100sec output, and 80 sec > > create_tria, and 45 sec assembly. Each core requires 9GB memory. This is > why I > > want to reduce memory usage. > > Yes, I can see why the reorder step is annoying then. > > Best > Wolfgang > > -- > ------------------------------------------------------------------------ > Wolfgang Bangerth email: bang...@colostate.edu > <javascript:> > www: http://www.math.colostate.edu/~bangerth/ > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
