[deal.II] Error calculating shape gradient

[A.Z Ihsan]

Hi all, 

i am getting this error while calculating the local cell matrix for my hp 
fem application

dealii::Tensor<1, spacedim> dealii::FEValuesBase> spacedim>::shape_grad_component(unsigned int, unsigned int, unsigned int) 
>> const [with int dim = 3; int spacedim = 3]
>
> The violated condition was: 
>
> component < fe->n_components()
>
> Additional information: 
>
> Index 1 is not in the half-open range [0,1).
>
> Stacktrace:
>
> ---
>
> #0  ../build/local: dealii::FEValuesBase<3, 
>> 3>::shape_grad_component(unsigned int, unsigned int, unsigned int) const
>
> #1  ../build/local: dealii::SymmetricTensor<2, 3, double> 
>> LinearElasticity::get_strain<3>(dealii::FEValues<3, 3> const&, unsigned 
>> int, unsigned int)
>
> #2  ../build/local: LinearElasticity::HPSolver<3, dealii::Vector 
>> >::assemble_cell_matrix(dealii::TriaActiveIterator> > 
>> 3>, false> > const&, dealii::FullMatrix&, dealii::hp::FEValues<3, 
>> 3>&)
>
> #3  ../build/local: 
>> LinearElasticity::HPSerialSolver<3>::assemble_linear_system(LinearElasticity::HPSerialSolver<3>::LinearSystem&)
>
> #4  ../build/local: LinearElasticity::HPSerialSolver<3>::solve_problem()
>
>  
>
>
The idea is similar to the tutorial step-27, but here i use the symmetric 
tensor for returning strain. Can someone explain to me what the error is 
and how to resolve it? 

BR, 
Ihsan

-- 
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/83d6f2cc-b746-4cb0-bf43-7b0e1d86f3bbo%40googlegroups.com.

Re: [deal.II] Particle Class Implementation

[Bruno Blais]

Dear Victoria,

In additional to what Jean-Paul suggested, you can look at the preliminary 
version of step-68 which does exactly what you would like to achieve with 
particles.
The code is available on the following pull request. Rene and I have put 
some work into it and it works quite well in its current state:
https://github.com/dealii/dealii/pull/10308

Best
Bruno


On Tuesday, 9 June 2020 16:06:15 UTC-4, Jean-Paul Pelteret wrote:
>
> Dear Victoria,
>
> You’re on the right track, but it looks like you got the syntax a bit 
> wrong. To create a particle you need to write something like
>
> Particles::Particle particle;
>
> You’ll note that the specific constructor that is called is inferred from 
> the arguments given to the instance of the class that’s being created (in 
> this case, no arguments —> default constructor).
>
> There is a new tutorial, namely step-70 
> , that uses 
> particles. I don’t know whether or not it’s pitched at the right level for 
> you to get to grips with some of the fundamentals (at first glance, it 
> seems to involve a number of more advanced techniques). If it’s not quite 
> tractable for you, then you could also take a look at some of the particle 
> tests  in 
> the test suite, such as this one 
> ,
>  
> that might provide snippets of information that you need as you build up 
> your understanding of this particular feature of the library.
>
> I hope that helps you a bit.
> Best,
> Jean-Paul
>
> On 09 Jun 2020, at 17:14, Victoria W. > 
> wrote:
>
> Hello, 
>
> I'm a new deal.ii and C++ user, so this question might be a bit basic, but 
> I was wondering how my implementation of the built-in deal.ii particle 
> class should look.  Ultimately I'm looking to track a particle in laminar 
> flow.  So far I've tried creating a simple particle at the origin after 
> generating my geometry with the GridGenerator class.  Calling the particle 
> class in my code looks like this: 
>
> Particles::Particle::Particle() 
>
> as per the documentation on dealii.org.  However I get the error message: 
> error: dependent-name ‘dealii::Particles::Particle::Particle’ is 
> parsed as a non-type, but instantiation yields a type.  How should I be 
> implementing this class to construct a particle, what type declaration 
> should new particles be declared as, and are there other documentation or 
> resources I should be looking at?  
>
> Thanks
>
> -- 
> 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 dea...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/43d0b22c-d736-464d-9d83-da4d819eca90o%40googlegroups.com
>  
> 
> .
>
>
>

-- 
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/579f09e4-b8ab-4197-8b05-dbd5e6fde291o%40googlegroups.com.

Re: [deal.II] Re: Broadcasting packed objects

[Wolfgang Bangerth]

On 6/9/20 2:53 PM, Maurice Rohracker wrote:

Thanks, Peter, that helped so far!

Another question would be, how would then the serialize function look like if 
one has another class as a member of a class. So, in this case, how would the 
serialize function look like if one has a class House and two of its member 
are of the type Room?

A serializing of nested objects so to speak.


The pack()/unpack() functions make use of the fact that many of the deal.II 
classes have save()/load() functions (sometimes combined into a serialize() 
function) that recursively save/load/serialize the member variables of these 
classes. Here is an example:

https://github.com/dealii/dealii/blob/master/include/deal.II/grid/tria.h#L4030-L4062

In these functions, operator& is used to serialize variables into/out of the 
given stream. If these variables are themselves classes, then that just calls 
these classes' respective save/load/serialize functions.


Best
 W.

--

Wolfgang Bangerth  email: bange...@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/f38c8e99-6394-923f-6efc-c7be12056bc7%40colostate.edu.

[deal.II] Re: Strategy to snap the boundary of a triangulation to a manifold

[Doug Shi-Dong]

Prof. Blais,

Bonjour fellow Montreal-er (McGill), land of the bagel and poutine.

I have also given some thoughts to robustly generate our meshes with GMSH.

I think it's great to see that we've concluded to similar steps as you 
described:

   1. Provide GMSH some CAD/NURBS parametrization from which can generate a 
   hex mesh (or tets which you manually subdivide).
   2. Read the mesh with linear elements into the Triangulation as well as 
   the NURBS parametrization as the Manifold.
   3. Represent the entire mesh as with a high-order polynomial-base by 
   associating the Triangulation with a MappingFEField with 
   FESystem(FE_Q(order)), where the DoF represent vertices locations. 
   (optional I guess)
   4. Use Manifold::project_to_manifold() as referred by 
   Prof. Bangerth to obtain displacements of the surface mesh. Surface points 
   already on the Manifold will have 0 displacements.
   5. Use elasticity equations just like in doi = {10.2514/6.2009-949} to 
   robustly displace the volume mesh, or use the optimization-based method 
   from the actual GMSH group doi = {10.1016/j.jcp.2012.08.051}.

A student in our group is tackling some of those steps later on. 

>From your previous post, it seemed that you have completed step 1 and 2. 
Step 4 really seems to be the missing ingredient.

I currently have step 3 and 5 for shape optimization, where the initial 
mesh is generated within deal.II and displacements in Step 4 are given by 
an optimizer. 
(ugly code: 
https://github.com/dougshidong/PHiLiP/tree/full_space_optimization/src/mesh)

I'd love to hear an update when you succeed

Doug

On Monday, June 8, 2020 at 12:22:08 PM UTC-4, Bruno Blais wrote:
>
> Dear all,
> I hope you are doing well.
>
> In my endless quest for robust mesh generation of hex meshes using GMSH, I 
> have managed to come up with a very robust strategy to generate hex-only 
> meshes
> My only issue (which is a major one) is that this implies that my 
> decomposition from tet to hex adds nodes that are not "snapped" to the 
> boundary, but that are only linear interpolation of the other node on the 
> triangular faces.
> Consequently, my quest remains unfulfilled.
>
> Meshing through high-order and snapping the additional node to a 
> high-order mesh from within GMSH is very troublesome and not very robust 
> (and also very time consuming). However, an idea came to mind.
> I was wondering if there could be an easy way to "snap" my faces to the 
> manifold to which they belong.
>
> My problem is thus the following:
> - Given a triangulation and a manifold
> - Some nodes are exactly on the manifolds (the original nodes of the tets) 
> and some are not (the added nodes in the subdivision)
> - What would be the best way to deform mesh so that the non-conforming 
> node get deformed to the position which would be implied by the manifold? I 
> think I could also make the process more robust by solving an additional 
> elasticity equation during the deformation to deform the entire mesh 
> instead of just the nodes close to the manifold.
>
>
> Would any of you have a suggestion on how best to achieve the deformation 
> of the nodes to match the manifold?
>
>
>

-- 
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/420fcb84-7c56-4469-8ee8-58ae4570edfeo%40googlegroups.com.

[deal.II] Re: Broadcasting packed objects

[Maurice Rohracker]

Thanks, Peter, that helped so far!

Another question would be, how would then the serialize function look like 
if one has another class as a member of a class. So, in this case, how 
would the serialize function look like if one has a class House and two of 
its member are of the type Room?
A serializing of nested objects so to speak.


Am Montag, 8. Juni 2020 14:19:25 UTC+2 schrieb peterrum:
>
> Dear Maurice,
>
> The problem is that the size of `auto buffer = 
> dealii::Utilities::pack(r1);` is not the same on all processes, which is a 
> requirement if you use `MPI_Bcast`. My suggestion would to split the 
> procedure into two steps: 1) bcast the size on rank 1; 2) bcast the actual 
> data.
>
> Peter
>
> On Monday, 8 June 2020 12:46:53 UTC+2, Maurice Rohracker wrote:
>>
>> Dear deal.II community,
>>
>> For a distributed implementation, we would like to broadcast packed data 
>> objects.
>>
>> For the beginning, we would like to understand how the serialize function 
>> for packing an object is working in the sense of the deal.II way, before it 
>> is getting more complicated.
>>
>> I created a small test with a class, which should be broadcasted. As a 
>> comparison, I took the dealii:Point, which can obviously be packed and 
>> broadcasted without any issues.
>>
>> Unfortunately, the broadcast for our class does not work. We assume that 
>> our serialize function is not in the correct manner. Is it possible to pack 
>> own objects using the dealii::Utilities:pack() function? What is the proper 
>> way defining the serialize function?
>>
>> Attached you'll find our small example code. We are using deal.II 9.0.1.
>>
>> Thank you very much in advance.
>>
>> Best regards,
>> Maurice Rohracker
>> Master Student Computational Engineering
>> FAU Erlange-Nürnberg
>>
>

-- 
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/31811f32-55a7-41d6-8a71-376e2a07cd76o%40googlegroups.com.

Re: [deal.II] About metallic ductile damage

[Jean-Paul Pelteret]

Dear Itachi,

To supplement what Bruno has already mentioned, deal.II provides some of the 
tools what you might find useful to implement constitutive laws or specific 
governing equations. To get some feeling as to what is possible, I would 
suggest that you take a look through the list of publications 
 to see what the community has achieved 
using deal.II. There are also several tutorials 
 and code-gallery 
contributions  (current and pending) 
that might give you insights into how you might go about implementing such a 
constitutive law within a solid-mechanics code. You might also with to look at 
the “Applications” listed in the top bar on the home page  
(I can’t give you a clickable link, I’m afraid). I believe that at least one of 
them (PRISMS) has a partial focus on plasticity.

Best,
Jean-Paul

> On 07 Jun 2020, at 17:01, Bruno Blais  wrote:
> 
> Dear Itachi,
> Deal.II is significantly different than abaqus in the fact that you easily 
> write you own equation and solve from it using whatever mean you find 
> necessary.
> However, it does not come readily built with a library of physical solvers or 
> constitutive laws. Consequently, you will have to build your own weak form 
> for your problem of interest (although this can be made much easier with 
> automatic differentiation facilities)..
> 
> So consequently, any user material can be defined in deal.II, but it is 
> significantly different than what you would obtained using a UMAT file for 
> instance.
> 
> Best
> Bruno
> 
> 
> On Saturday, 6 June 2020 16:08:47 UTC-4, itachi Ezio wrote:
> Hi,
> 
> I'm Abaqus user and fresh new about using deal.II. I'd like to ask a few 
> questions base on deal.II functions.
> 
> I'm looking for the simulation for metallic ductile damage behavior with 
> deal.II ( for example with triaxiality and lode angle), is it possible?
> 
> And how is it like to write user materials in deal.II, especially in 
> plasticity behaviors? Is it also quit sophisticated as in UMAT in Abaqus?
> 
> Looking forward to the answers, thanks for that!  
> 
> 
> 
> -- 
> 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/c535b46f-c2a6-4db9-ac58-c25bca4dbbeco%40googlegroups.com
>  
> .

-- 
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/1932E000-0010-48C2-84C1-60B18A00DE10%40gmail.com.

Re: [deal.II] Deal.ii installation

[Jean-Paul Pelteret]

Dear Prasad,

I’m glad to hear that you solved your problem. I must say, though, that the 
problem and the solution only seems to me to be tangentially related.  Although 
neither you, I, nor probably anyone else could have guessed from the cryptic 
and nondescript error message, you were probably missing some critical core 
package required to build the library. Many of these dependencies would be 
installed via

sudo apt-get install build-essential  

but it could be that something else is required. Here, for example, is a list 
of the packages assumed to be installed when building deal.II using Candi.

https://github.com/dealii/candi/blob/master/deal.II-toolchain/platforms/supported/ubuntu20.platform#L6-L10

Note through that many of these packages would only be required by the 
dependencies (e.g. Trilinos). The key one there is, again, probably 
build-essential . But this is just speculation - I currently don’t have an 
Ubuntu installation with to test my suspicion. But I thought I’d just share my 
thoughts in case someone else hits the same problem and spots this thread while 
looking for a solution.

Best,
Jean-Paul

> On 03 Jun 2020, at 19:24, Prasad Adhav  wrote:
> 
> I was able to solve the issue by installing trilinos-all-dev.
> 
> ~$ sudo apt-get update -y
> ~$ sudo apt-get install -y trilinos-all-dev
> 
> Download Deal.ii
> Moved it to bin
> 
> ~/bin$ tar -xvf deal.II-9.1.1.tar.gz
> ~/bin/dealii-9.1.1$ mkdir build
> ~/bin/dealii-9.1.1$ cd build
> ~/bin/dealii-9.1.1/build$ cmake 
> -DCMAKE_INSTALL_PREFIX=/home/prasad/bin/deal.II ..
> ~/bin/dealii-9.1.1/build$ make install
> ~/bin/dealii-9.1.1/build$ make test
> 
> prasad@XDEM-laptop:~/bin/dealii-9.1.1/build$ make test 
> Scanning dependencies of target test 
> Running quicktests... 
> Test project /home/prasad/bin/dealii-9.1.1/build/tests/quick_tests 
>Start 1: step.debug 
>Start 2: step.release 
>Start 3: affinity.debug 
>Start 4: tbb.debug 
>Start 5: lapack.debug 
>Start 6: umfpack.debug 
>Start 7: boost_zlib.debug 
>Start 8: gmsh.debug 
> 1/8 Test #5: lapack.debug .   Passed   34.73 sec 
> 2/8 Test #4: tbb.debug    Passed   38.34 sec 
> 3/8 Test #8: gmsh.debug ...   Passed   44.55 sec 
> 4/8 Test #7: boost_zlib.debug .   Passed   44.97 sec 
> 5/8 Test #3: affinity.debug ...   Passed   44.98 sec 
> 6/8 Test #6: umfpack.debug    Passed   48.18 sec 
> 7/8 Test #2: step.release .   Passed   52.11 sec 
> 8/8 Test #1: step.debug ...   Passed   54.85 sec 
> 
> 100% tests passed, 0 tests failed out of 8 
> 
> Total Test time (real) =  54.85 sec 
> Built target test
> 
> 
> On Monday, April 27, 2020 at 11:27:31 AM UTC+2, Prasad Adhav wrote:
> Hello,
> 
> I am trying to install deal.ii for the first time.
> I followed the instructions on the readme 
> page(https://www.dealii.org/current/readme.html 
> )
> 
> I use the following for cmake and it worked fine:
> 
> prasad@XDEM-laptop:~/Downloads/dealii-9.1.1/build$ cmake 
> -DCMAKE_INSTALL_PREFIX=/home/
> prasad/Downloads/dealii-9.1.1/dealii_install/ ..
> 
> Then I tried to do `make`, `make info` and `make install`, I get a similar 
> error as follows:
> prasad@XDEM-laptop:~/Downloads/dealii-9.1.1/build$ make info 
> make: *** No rule to make target 'info'.  Stop.
> 
> prasad@XDEM-laptop:~/Downloads/dealii-9.1.1/build$ make install 
> make: *** No rule to make target 'install'.  Stop.
> 
> I apologize if this was already posted, in my search I did not find any 
> questions similar to this.
> Can anyone help with this?
> Thank you.
> 
> 
> 
> 
> -- 
> 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/8ff0c50c-0433-4ed3-950b-fb2b1f754f96%40googlegroups.com
>  
> .

-- 
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/deal

Re: [deal.II] Particle Class Implementation

[Jean-Paul Pelteret]

Dear Victoria,

You’re on the right track, but it looks like you got the syntax a bit wrong. To 
create a particle you need to write something like

Particles::Particle particle;

You’ll note that the specific constructor that is called is inferred from the 
arguments given to the instance of the class that’s being created (in this 
case, no arguments —> default constructor).

There is a new tutorial, namely step-70 
, that uses particles. 
I don’t know whether or not it’s pitched at the right level for you to get to 
grips with some of the fundamentals (at first glance, it seems to involve a 
number of more advanced techniques). If it’s not quite tractable for you, then 
you could also take a look at some of the particle tests 
 in the test 
suite, such as this one 
, 
that might provide snippets of information that you need as you build up your 
understanding of this particular feature of the library.

I hope that helps you a bit.
Best,
Jean-Paul

> On 09 Jun 2020, at 17:14, Victoria W.  wrote:
> 
> Hello, 
> 
> I'm a new deal.ii and C++ user, so this question might be a bit basic, but I 
> was wondering how my implementation of the built-in deal.ii particle class 
> should look.  Ultimately I'm looking to track a particle in laminar flow.  So 
> far I've tried creating a simple particle at the origin after generating my 
> geometry with the GridGenerator class.  Calling the particle class in my code 
> looks like this: 
> 
> Particles::Particle::Particle() 
> 
> as per the documentation on dealii.org.  However I get the error message: 
> error: dependent-name ‘dealii::Particles::Particle::Particle’ is 
> parsed as a non-type, but instantiation yields a type.  How should I be 
> implementing this class to construct a particle, what type declaration should 
> new particles be declared as, and are there other documentation or resources 
> I should be looking at?  
> 
> Thanks
> 
> -- 
> 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/43d0b22c-d736-464d-9d83-da4d819eca90o%40googlegroups.com
>  
> .

-- 
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/4E5FB693-EBAE-4202-A773-561D6A56E6C7%40gmail.com.

[deal.II] Particle Class Implementation

[Victoria W.]

Hello, 

I'm a new deal.ii and C++ user, so this question might be a bit basic, but 
I was wondering how my implementation of the built-in deal.ii particle 
class should look.  Ultimately I'm looking to track a particle in laminar 
flow.  So far I've tried creating a simple particle at the origin after 
generating my geometry with the GridGenerator class.  Calling the particle 
class in my code looks like this: 

Particles::Particle::Particle() 

as per the documentation on dealii.org.  However I get the error message: 
error: dependent-name ‘dealii::Particles::Particle::Particle’ is 
parsed as a non-type, but instantiation yields a type.  How should I be 
implementing this class to construct a particle, what type declaration 
should new particles be declared as, and are there other documentation or 
resources I should be looking at?  

Thanks

-- 
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/43d0b22c-d736-464d-9d83-da4d819eca90o%40googlegroups.com.

Re: [deal.II] Strategy to snap the boundary of a triangulation to a manifold

[heena patel]

Dear Bruno,
   I am not expert, but OpenFoam has Snappyhex mesh
feature that might help you. Check the link below.
http://www.wolfdynamics.com/wiki/meshing_OF_SHM.pdf

Regards,
Heena

On Mon, Jun 8, 2020 at 6:22 PM Bruno Blais  wrote:

> Dear all,
> I hope you are doing well.
>
> In my endless quest for robust mesh generation of hex meshes using GMSH, I
> have managed to come up with a very robust strategy to generate hex-only
> meshes
> My only issue (which is a major one) is that this implies that my
> decomposition from tet to hex adds nodes that are not "snapped" to the
> boundary, but that are only linear interpolation of the other node on the
> triangular faces.
> Consequently, my quest remains unfulfilled.
>
> Meshing through high-order and snapping the additional node to a
> high-order mesh from within GMSH is very troublesome and not very robust
> (and also very time consuming). However, an idea came to mind.
> I was wondering if there could be an easy way to "snap" my faces to the
> manifold to which they belong.
>
> My problem is thus the following:
> - Given a triangulation and a manifold
> - Some nodes are exactly on the manifolds (the original nodes of the tets)
> and some are not (the added nodes in the subdivision)
> - What would be the best way to deform mesh so that the non-conforming
> node get deformed to the position which would be implied by the manifold? I
> think I could also make the process more robust by solving an additional
> elasticity equation during the deformation to deform the entire mesh
> instead of just the nodes close to the manifold.
>
>
> Would any of you have a suggestion on how best to achieve the deformation
> of the nodes to match the manifold?
>
>
> --
> 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/8d966870-4e33-4915-ad6c-2342018d82c3o%40googlegroups.com
> 
> .
>

-- 
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/CAG_Oxbi8HmVd26w2ChrtC6yfhCd8k6dV40Kq7apt-sxhUhJodQ%40mail.gmail.com.