Re: [deal.II] Finding gradient of divergence over divergence normal
Thank you for your answer. Yes, I want to evaluate the quantity at quadrature points. This is a source term (Continuum Surface Force) that should be added to the (Navier-Stokes) equations. On Friday, January 28, 2022 at 3:04:14 PM UTC-5 Wolfgang Bangerth wrote: > On 1/28/22 7:56 AM, shahab.g...@gmail.com wrote: > > > > I am looking for a way to obtain the distribution of ∇.(∇C/|∇C|) where C > is > > the main variable and I have its distribution (values, gradients and > > laplacians) over the domain. This is used for finding the normal vector > and > > its divergence over the moving interface of two materials in a > simulation. I > > would appreciate any suggestions you might have. > > When you say "obtain the distribution of ..." do you mean that you want to > evaluate that quantity at individual (quadrature) points? Or what do you > want > to do with it? > > The quantity you are looking at is not well defined for the usual finite > elements: grad C is a disontinuous function, and taking the divergence is > going to exacerbate the problems with this expression. The question > therefore > is what you want to do with it. A common approach is to use it in a weak > formulation where you can integrate by parts to get rid of the divergence. > > Best > 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 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/b3e7b312-e438-49ee-a049-09a68f9ffdb8n%40googlegroups.com.
[deal.II] Finding gradient of divergence over divergence normal
Dear all, I am looking for a way to obtain the distribution of ∇.(∇C/|∇C|) where C is the main variable and I have its distribution (values, gradients and laplacians) over the domain. This is used for finding the normal vector and its divergence over the moving interface of two materials in a simulation. I would appreciate any suggestions you might have. Regards, Shahab -- 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/270cac7e-7272-4d08-bf74-820e01566321n%40googlegroups.com.
Re: [deal.II] Re: Grid deformation after load-balancing
Dear Wolfgang, Bruno and Peter, Thank you for your helps. It was my fault for not reading the entire function's documentation before asking the question here. Best Shahab On Wednesday, August 4, 2021 at 10:16:44 AM UTC-4 blais...@gmail.com wrote: > Yeah I expected this... > I would not know how to do this either. It would require that every > manifold has some sort of "center of mass" variable that would be used to > define the centroid of the manifold, but that would be some pretty heavy > stuff to refactor and I am not sure it would lead to a cleaner design. > > You are right that this is already very well documented in the > GridTools::transform() documentation :). I need to learn to read the > documentation a bit more before asking :) > > > > On Wednesday, August 4, 2021 at 10:11:03 a.m. UTC-4 Wolfgang Bangerth > wrote: > >> On 8/4/21 6:57 AM, blais...@gmail.com wrote: >> > >> > Is that not a bit of an ill-defined behavior for the triangulations? >> Shouldnt >> > the manifolds also translate themselves when the triangulation is >> translated? >> >> This is a discussion we had at some point when we looked at the >> GridTools::transform() function where that issue is even documented. >> You're >> right that in principle, one would want to transform the manifold along >> with >> the mesh, but nobody had an idea of how to do that in practice. >> >> Best >> 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 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/cfa54ce1-99f9-406f-8b36-4e17b876879bn%40googlegroups.com.
[deal.II] Re: Grid deformation after load-balancing
Dear Bruno, Thank you for your reply. I am 100% sure that this is not a rendering issue, because in my solver the particles that are located on top of this boundary are influenced by the deformation of the cells. How can I exactly quantify the deformation? Best, Shahab On Thursday, July 29, 2021 at 2:50:09 PM UTC-4 bruno.t...@gmail.com wrote: > Shahab, > > Can you quantify the deformation? It would be useful if you could output > the coordinates of the vertices of the deformed cells before and after load > balancing. It is possible that's a rendering issue but it's hard to tell > without having numbers. > > Best, > > Bruno > > On Wednesday, July 28, 2021 at 6:48:50 PM UTC-4 shahab.g...@gmail.com > wrote: > >> Dear All, >> >> I have noticed that some moving grids get deformed after load-balancing. >> I should mention that this only happens when I move the grid using >> GridTools::rotate or GridTools::shift, and only for curved geometries. For >> instance, it doesn't happen in a box, but I've observed this problem in >> cylinders. Furthermore, only the cells which are exchanged between the >> processors during load-balancing get deformed. I've attached an image of >> this problem. It shows a rotating cylinder. On the left, it shows the >> triangulation output before load-balancing. On the right, you can see the >> triangulation after load-balancing and how the exchanged cells are deformed >> (inside the red circle). >> >> I would appreciate it if you give me any suggestions about the reason for >> this problem. Thank you in advance. >> >> Best regards, >> Shahab >> > -- 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/5b5391e8-ac92-4499-a904-8b842967701fn%40googlegroups.com.
[deal.II] Writing outputs of type tensor in cells
Dear All, I have a parameter of type Tensor<1, dim> for each active cell in the triangulation. When I write this parameter as output, I face some difficulties: 1, Vectors in deal.II do not accept tensor elements. 2, add_data_vector does not work for std::vectors. 3, I tried using DataComponentInterpretation, but I am really confused in implementing it correctly. I would appreciate it if you could send me an example of writing an output of type Tensor for each cell. Let's say I have a std::vector> output; , and in this vector I've stored the output parameter in each cell using cell->global_active_cell_index(). Best Shahab -- 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/58aef5ba-eaa5-4a27-9ae8-64f56d742adbn%40googlegroups.com.
Re: [deal.II] Clearing a particle properties without getting properties for each particle
Not here, but it other functions it would be very useful to be able to map back to the owning particle. In fact, I have to treat local and ghost particles differently. In terms of updating properties, I only need to update the properties of local particles. When the maximum displacement of a particles reaches half of the cell length in the triangulation, I call sort_particles_into_subdomains_and_cells() to update the list of local and ghost particles. I can explain the algorithm in more details if you want. Thanks again. Shahab On Thursday, December 3, 2020 at 10:54:42 PM UTC-5 Wolfgang Bangerth wrote: > On 12/3/20 4:13 PM, shahab.g...@gmail.com wrote: > > I want to iterate through all the particles in each iteration of my > solver and > > update some of the properties. The problem is iterating through > particles > > using particle_handler() is rather computationally expensive. I am > looking for > > a way to update the properties without iterating through the > particle_handler. > > I see. > > So you'd need to iterate through the the blocks of properties stored in > the > PropertyPool? We could write such an interface, but let me ask a couple of > questions first: > * Do you need to map back from block of memory to the owning particle? > * Will you somehow need to treat ghost particles differently than the > locally > owned ones? How will you make sure that locally owned particles on one > processor stay in sync with the corresponding ghost particles on the other > processor(s)? > > Best > 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 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/2796d59e-3e02-4888-91d5-2b9dc148ec5en%40googlegroups.com.
Re: [deal.II] Clearing a particle properties without getting properties for each particle
Thanks for the reply. I want to iterate through all the particles in each iteration of my solver and update some of the properties. The problem is iterating through particles using particle_handler() is rather computationally expensive. I am looking for a way to update the properties without iterating through the particle_handler. Best regards, Shahab On Thursday, December 3, 2020 at 4:46:33 PM UTC-5 Wolfgang Bangerth wrote: > On 12/3/20 1:19 PM, shahab.g...@gmail.com wrote: > > Can you please write an example of accessing memory pool handles, > iterating > > them and converting the handles to particle properties? > > The way we think about it is that the MemoryPool stores the data in some > way > that should not be of any concern to you. You access these properties > through > the particles they are attached to. As a user you don't have contact with > the > PropertyPool at all. > > At least that was the original idea. Can you explain what you're trying to > do? > > Best > 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 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/55ace764-efa4-45dc-abb1-233a9c5e5b4en%40googlegroups.com.
Re: [deal.II] Clearing a particle properties without getting properties for each particle
Hi,
Can you please write an example of accessing memory pool handles, iterating
them and converting the handles to particle properties?
Thanks in advance.
Best regards,
Shahab
On Monday, October 19, 2020 at 10:57:26 PM UTC-4 Wolfgang Bangerth wrote:
> On 10/19/20 9:03 AM, blais...@gmail.com wrote:
> > I am not sur if I fully understand the memory structure of the Property
> Pool
> > (or at least I am still confused by it).
> > If I understand correctly, the properties of all the particles are
> stored in a
> > single Handle array and the get_properties of a single particle returns
> an
> > array view pointing to this large array.
> > However, the n_properties_per_slot() returns the number of properties
> > associated with a single particle. Is there a way to know from within
> the
> > property pool the size of the handle array?
>
> Maybe
> https://github.com/dealii/dealii/pull/11057
> clarifies the intent of the PropertyPool? The idea is that the property
> pool
> is responsible for all of the memory allocated for particle properties.
>
> I've come to realize that what you want to do wasn't possible in the
> current
> design (because we don't keep track of which memory we have allocated), so
> wrote
> https://github.com/dealii/dealii/pull/11059
>
> Once that is merged, I think what you want to do is maybe something along
> the
> lines of the following addition to the PropertyPool class:
>
> /**
> * Return the first of all of the memory pool handles that are managed
> * by this class. Iterating from begin() to end() then returns the handles
> * associated with all particles in the ParticleHandler class that owns
> * this property pool; using the get_properties() function, these handles
> * can be converted to ArrayView objects that then allow access to the
> * actual properties.
> *
> * This function can be used to access and modify the properties of all
> * particles, though possibly in a different order than if one accessed
> * them using ParticleHandler::begin() and ParticleHandler::end().
> *
> * @note PropertyPools also store the properties of ghost particles,
> * and consequently iterating over all handles also reaches the
> * properties of ghost particles.
> */
> std::set::iterator begin ()
> { return currently_open_handler.begin() }
>
> + same for the corresponding end() function.
>
>
> > If the properties are stored in a continuous block, one could easily
> write a
> > function that takes into argument a vector of property index, the value
> to set
> > and the number of particles for example. This function would then be
> called
> > from the particle handler which in turn would have an interface to this
> > function with the vector of property index and the value to set.
> > Would that be the right approach? If so, I can work on a PR.
>
> PropertyPool doesn't advertise how it stores properties. Currently, it's
> not
> in one large block, though that's something we might want to change at
> some
> future point. The interface above avoids exposing how exactly they are
> stored.
>
> Best
> 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 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/0ef442aa-6197-47c6-b7ca-b40c04e340edn%40googlegroups.com.
[deal.II] Separated domains in load balanding
Dear all, I am using load balancing and I noticed after load balancing, that the cells owned by each processor are sometimes separated from each other. In other words, some processors may own cell domains that are not connected to each other. As this increases the computational cost in my case, I was wondering whether it would be possible to limit the load balancing to define only adjacent cells? Thank you for your helps in advance. Best regards, Shahab -- 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/7b941286-61ee-436d-92b1-8bf032026128n%40googlegroups.com.
