Dear Professor Bangerth, thank you very much for your reply and please excuse my late answer. Unfortunately I didn't have the time the last couple of days to work on this problem or further investigate it. I have edited the pack_callback() function in solution_transfer.cc a little bit myself before your reply and made further progress on this problem (and in return created some other problems...). I will do some more research the next couple of days on this topic and report back here.
Thanks for your help, Mathias Am Dienstag, 20. August 2019 01:07:04 UTC+2 schrieb Wolfgang Bangerth: > > > Mathias, > > > thanks again for your reply, I will start answering your questions and > > give you more insight into what I try to do at the moment: > > > > That's exactly the question you have to answer first. What do you > > *want* to > > happen on these cells? If you know what you want to happen, we can > > talk about > > implementing it :-) > > > > > > In my current Cut FEM approach I'm interested in the solution on the > > "physical domain", in my case that's the solution on the (moving) flow > > domain including all the boundaries (also on the solid moving ball). > > Since I don't adjust the grid to the problem I have also a kind of "flow > > domain" inside the solid, which is nonphysically. I don't want to see > > any effect of these "nonphysical cells" on my "physical cells", so the > > natural approach to me was using FE_Nothing - and this is perfect for > > the static case and does the job very well (I don't have a fluid domain > > inside the solid and additionally I save some DoFs inside the solid, > > which is a nice side effect, but not crucial to me). Therefore I would > > like to also use this possibility in the dynamic case, so I would like > > to go for the 1.) approach in my first post. > > What I meant to say is this: Say your domain moves and a cell that used > to be in the solid (=nonphysical) now becomes part of the fluid > (=physical). If you have a time-dependent problem (or a nonlinear > problem), your current solution will have degrees of freedom on this > cell, but the previous solution does not. But you need to compute a time > derivative, or a Newton update on this cell -- you will somehow have to > define what the *previous* solution should be on the cell in question > when there were no previous degrees of freedom there. > > You answered that question here: > > > That's indeed the crucial point that I have to answer. What I definitely > > need, are more DoFs, when the solid moves outside a FE_Nothing cell. The > > question is what the value of my old solution on these cells shall be. I > > guess there are several possibilities e.g. a "fancy one" like > > extrapolating the solution from the physical domain from the step before > > to the now activated cell. But this is not what I want to do in this > > first step now. I just want to set the solution on these cell to "0" > > (knowing that probably an extrapolation would be better as a first > > guess, but since it is just a starting value for my solver, I guess the > > "0"-approach is good enough). > > > > This behavior is of course not implemented in deal.ii at the moment. > > What I did to reflect the above answer is that I improved my naive > > approach, which I described in my first post here, a little bit and do > > the following now: > > > > 1. initialize a parallel::distributed::SolutionTransfer object and add > > my old (ghosted) solution vectors via > > prepare_for_coarsening_and_refinement > > 2. check if we have a cell that get's "activated"(change from > > FE_Nothing to my FE_System for my flow problem) or "deactivated" > > (other way around). If this is the case, I do: > > 1. update the fe_indices > > 2. call execute_coarsening_and_refinement() on the triangulation > > 3. distribute the new DoFs > > 4. create a new sparsity pattern and reinitialize my system matrix > > with it > > 5. create a new solution vector with the new (locally owned) DoFs > > 6. interpolate the solution to this new solution vector using > > SolutionTransfer::interpolate() > > That seems like a reasonable workflow. > > > This works again in the static case, also if I omit the check in step 2 > > and do the whole process even if it's not necessary. In the dynamic case > > step 6 fails: > > > > SolutionTransfer::interpolate() leads to the > > SolutionTransfer::unpack_callback() function called by the tria, which > > calls set_dof_values_by_interpolation() on the cell. > > This calls set_dof_values() and the following assertion fails: > > > > Assert(values.size() == this->get_dof_handler().n_dofs(), > > typename DoFCellAccessor::ExcVectorDoesNotMatch()); > > > > > > which is of course understandable. At the moment I'm trying to > > understand the internals of the unpack process and look for a nice way > > to implement what I described above - so any help or advice is greatly > > welcomed :) > > I don't understand how we arrive at this exact place, but I can think of > many scenarios where the class is simply not prepared to interpolate > from an FE_Q to an FE_Nothing or the other way around. Do you think you > can create an artificial testcase that shows exactly the kind of problem > you have? I.e., a situation where you create a mesh with just a few > cells (as few as possible), distribute DoFs on it, create a vector, and > then change the active_fe_index pattern before you call > SolutionTransfer? The test doesn't need to compute anything -- just > leave the vectors you have at zero, or initialize them with random data. > The point is simply to come up with as simple a testcase that shows the > assertion you mention above. > > Best > W. > > > -- > ------------------------------------------------------------------------ > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/bbb3df87-00c4-4fa4-aa4b-0a832b9e1ef9%40googlegroups.com.
