Hi Kaushik,
Yes, this is possible by changing a cell from FE_Nothing to FE_Q using p-refinement. You can do this with the method described in #11132 <https://github.com/dealii/dealii/pull/11132>: Imitate what p::d::SolutionTransfer is doing with the more versatile tool p::d::CellDataTransfer and consider the following: - Prepare a data container like `Vector<Vector<double>>` where the outer layer represents each cell in the current mesh, and the inner layer corresponds to the dof values inside each cell. - Prepare data for the updated grid on the old grid. - On already activated cells, store dof values with `cell->get_interpolated_dof_values()`. - On all other cells, store an empty container. - Register your data container for and execute coarsening and refinement. - Interpolate the old solution on the new mesh. - Initialize your new solution vector with invalid values `std::numeric_limits<double>::infinity`. - On previously activated cells, extract the stored data with `cell->set_dof_values_by_interpolation()`. - Skip all other cells which only have an empty container. - On non-ghosted solution vectors, call `compress(VectorOperation::min)` to get correct values on ghost cells. This leaves you with a correctly interpolated solution on the new mesh, where all newly activated dofs have the value `infinity`. You can now (and not earlier!!!) assign the values you have in mind for the newly activated dofs. You may want to exchange data on ghost cells once more with `GridTools::exchange_cell_data_to_ghosts()`. This is a fairly new feature in the library for a very specific use case, so there is no dedicated class for transferring solutions across finite element activation yet. If you successfully manage to make this work, would you be willing to turn this into a class for the deal.II library? Marc On Wednesday, December 30, 2020 at 8:22:59 AM UTC-7 k.d...@gmail.com wrote: > Hi all, > Thank you for your reply. > Let me explain what I am trying to do and why. > I want to solve a transient heat transfer problem of the additive > manufacturing (AM) process. In AM processes, metal powder is deposited in > layers, and then a laser source scans each layer and melts and bonds the > powder to the layer underneath it. To simulate this layer by layer process, > I want to start with a grid that covers all the layers, but initially, only > the bottom-most layer is active and all other layers are inactive, and then > as time progresses, I want to activate one layer at a time. I read on this > mailing list that cell "birth" or "activation" can be done by changing a > cell from FE_Nothing to FE_Q using p-refinement. I was trying to keep all > cells of the grid initially to FE_Nothing except the bottom-most layer. And > then convert one layer at a time to FE_Q. My questions are: > 1. Does this make sense? > 2. I have to do two other things for this to work. (a) When a cell becomes > FE_Q from FE_Nothing, dofs that are activating for the 1st time, I need to > apply a non-zero initial value to those dofs. This is to simulation the > metal powder deposited at a specified temperature,. e.g. room temperature. > (b) the dofs, that were shared between a FE_Q and FE_Nothing cells before > the p-refinement and now shared between FE_Q and FE_Nothing cells after > refinement, should retrain their values from before the refinement. > > Another way to simulation this process would be to use a cell "awaking" > process, instead of the cell "birth". I keep call cells FE_Q but apply a > very low diffusivity to the cells of the layers that are not yet "awake". > But this way, I have to solve a larger system in all time steps. I was > hoping to save some computation time, by only forming a system consists of > cells that are in the "active" layers only. > > Please let me if this makes sense? Is there any other method in deal.ii > that can simulation such a process? > Thank you very much and happy holidays. > Kaushik > > > On Tue, Dec 29, 2020 at 12:26 PM Wolfgang Bangerth <bang...@colostate.edu> > wrote: > >> On 12/28/20 5:11 PM, Marc Fehling wrote: >> > >> > In case a FE_Nothing has been configured to dominate, the solution >> should be >> > continuous on the interface if I understood correctly, i.e., zero on >> the face. >> > I will write a few tests to see if this is actually automatically the >> case in >> > user applications. If so, this check for domination will help other >> users to >> > avoid this pitfall :) >> > >> >> More tests = more better :-) >> Cheers >> W. >> >> -- >> ------------------------------------------------------------------------ >> Wolfgang Bangerth email: bang...@colostate.edu >> 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 a topic in the >> Google Groups "deal.II User Group" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/dealii/ssEva6C2PU8/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> dealii+un...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/dealii/0398a440-3ee2-9642-9c27-c519eb2f12e5%40colostate.edu >> . >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/10c3ef9f-88d7-43a7-a2ad-e689286513b7n%40googlegroups.com.
