Re: [deal.II] Minimal deal.ii application loads many surprising dynamic libraries on macos

[blais...@gmail.com]

Dear Jack,
Interesting you took a look at this. I was always wondering why lethe takes 
forever to start on my ARM M1 Mac compared to on a regular Linux desktop. 
Seems you figured it out...
However, I am unsure of the solution for this.
Orthogonally to this, have you ever managed to have cmake ctest command 
work correctly with dylib files under this setup?
Best
Bruno


On Saturday, April 20, 2024 at 12:11:16 a.m. UTC+2 johnbc...@gmail.com 
wrote:

> Wolfgang,
>
> Thank you for the reply, I'm glad to see that the developers are keeping 
> an eye on dependencies and startup time.
>
> In my case, I was actually careful to compile deal.ii ONLY against MPI, so 
> there are only seven direct deps, mostly from my homebrew installation of 
> openmpi. But after figuring out the correct tooling to do this on macos and 
> digging a little more, it seems that openmpi's libhwloc is the culprit. 
> Once it pulls in Foundation.framework and IOKit.framework, we are really 
> off to the races.
>
> It appears that my ubuntu build in a docker container starts up in about 
> half the time (also just built against MPI).
>
> -Jack
>
> On Friday, April 19, 2024 at 2:00:29 PM UTC-7 Wolfgang Bangerth wrote:
>
> On 4/18/24 23:29, Jack Coughlin wrote: 
> > 
> > As I say, I don't understand the issue well enough to know if there is 
> > anything I or the deal.ii developers can do about it! In any case, 0.25s 
> is a 
> > very small price to pay for so much functionality and expressiveness. 
>
> Jack, 
> I appreciate the qualification in the last sentence :-) 
>
> I don't have a Mac, so can't repeat the experiment and tell you what these 
> ~100 libraries are, but I've looked into this on my Linux laptop. There, 
> libdeal_II.g.so directly references the following 54 libraries: 
>
> Part of Trilinos: 
> libnox.so.13 
> libamesos2.so.13 
> libtacho.so.13 
> libml.so.13 
> libifpack.so.13 
> libamesos.so.13 
> libaztecoo.so.13 
> libtrilinosss.so.13 
> libtpetra.so.13 
> libtpetraclassicnodeapi.so.13 
> libepetraext.so.13 
> libzoltan.so.13 
> libepetra.so.13 
> libkokkoskernels.so.13 
> libteuchoscomm.so.13 
> libteuchosparameterlist.so.13 
> libteuchoscore.so.13 
> libkokkoscore.so.13 
> libsuperlu_dist.so.5 
>
> HDF5: 
> libhdf5.so.103 
>
> Part of OpenCASCADE: 
> libTKBool.so.11 
> libTKBRep.so.11 
> libTKernel.so.11 
> libTKG3d.so.11 
> libTKGeomAlgo.so.11 
> libTKGeomBase.so.11 
> libTKMath.so.11 
> libTKMesh.so.11 
> libTKShHealing.so.11 
> libTKTopAlgo.so.11 
> libTKXSBase.so.11 
> libTKIGES.so.11 
> libTKSTEP.so.11 
> libTKSTL.so.11 
>
> PETSc and SLEPc: 
> libslepc.so.3.16 
> libpetsc.so.3.16 
> libmetis.so 
>
> MPI: 
> libmpi_cxx.so.40 
> libmpi.so.40 
>
> SUNDIALS: 
> libsundials_idas.so.4 
> libsundials_arkode.so.4 
> libsundials_kinsol.so.5 
> libsymengine.so.0.8 
>
> BLAS and LAPACK: 
> liblapack.so.3 
> libblas.so.3 
>
> p4est: 
> libp4est.so.0 
> libsc.so.0 
>
> System and compiler libraries: 
> libgmp.so.10 
> libz.so.1 
> libm.so.6 
> libstdc++.so.6 
> libgcc_s.so.1 
> libc.so.6 
> ld-linux-x86-64.so.2 
>
> These are all libraries from which deal.II directly utilizes 
> functionality. It 
> is so many because some of the packages we rely on (notably Trilinos and 
> OpenCASCADE) split their functionality into many separate libraries for 
> reasons unknown to me. 
>
> Beyond these 54, every executable then pulls in another 27 libraries. 
> These 
> are libraries that, directly or indirectly, one of the 57 above 
> references. 
> For me, these are: 
>
> More from Trilinos: 
> libgaleri-epetra.so.13 
> libHYPRE-2.23.0.so 
> libkokkoscontainers.so.13 
> libteuchosnumerics.so.13 
> libteuchosparser.so.13 
> libteuchosremainder.so.13 
> libthyracore.so.13 
> libtriutils.so.13 
>
> More from OpenCASCADE: 
> libTKBO.so.11 
> libTKG2d.so.11 
> libTKPrim.so.11 
> libTKSTEP209.so.11 
> libTKSTEPAttr.so.11 
> libTKSTEPBase.so.11 
>
> More from PETSc: 
> libparmetis.so 
>
> More from MPI: 
> libmpi_mpifh.so.40 
> libopen-pal.so.40 
> libopen-rte.so.40 
>
> More compiler libraries: 
> libgfortran.so.5 
> libgomp.so.1 
> libhwloc.so.15 
> libquadmath.so.0 
>
> Unclear to me: 
> libevent_core-2.1.so.7 
> libevent_pthreads-2.1.so.7 
> libmvec.so.1 
> libudev.so.1 
> linux-vdso.so.1 (0x7ffc27ddc000) 
>
>
> The example you show, libAudioStatistics.dylib, would fall into this last 
> category. It would be interesting to see which of the dependencies pulls 
> it 
> in. In general, though, from the example above, nearly everything I see is 
> there for a fairly good reason. 
>
> I will note that you can very substantially slim down if you trim all of 
> the 
> dependencies. You can build deal.II without reference to Trilinos, PETSc, 
> and 
> a lot of other stuff, and it compiles substantially faster and is 
> substantially smaller. It will of course also have substantially less 
> functionality :-) 
>
> Best 
> W. 
>
> -- 
>  
> Wolfgang Bangerth email: 

[deal.II] Re: Helping collaborators write a cluster module for deal.II

[blais...@gmail.com]

Dear David,
The Digital Alliance of Canada (Compute Canada) has deal.II on their 
cluster through the use of the module system:
https://docs.alliancecan.ca/wiki/Available_software

You could reach out to them and ask them for their module file. They are 
generallly very chill.
If you need help reaching out, ask me and I can write to them with you in 
CC.
Best
Bruno


On Wednesday, November 15, 2023 at 8:00:08 a.m. UTC-5 Wells, David wrote:

> Hi everyone,
>
> I'm working with a group at another university on a deal.II-powered 
> project (yay). I'd like to set things up as a module (i.e., do module load 
> dealii/9.5.1) so that everyone there is using the same version of 
> everything.
>
> Are there any published versions of deal.II modules for various Linux 
> distributions? Every cluster is different but it would be super helpful to 
> see what other people have done to install deal.II and dependencies in this 
> situation.
>
> Best,
> David Wells
>

-- 
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/fc271591-d715-49b8-bdb0-471b8eca38a3n%40googlegroups.com.

Re: [deal.II] Liltle help with MUMPS

[blais...@gmail.com]

In addition to what Wolfgang wrote,
Sometimes the OS will map the cores of a CPU in the following order:
Physical-Logical-Physical-Logical-Physical-Logical etc.
Consequently, if your processor supports hyperthreading through the use of 
logical core, running with core 0-1 means you are essentially running on a 
single physical core but using two logical cores. For intensive operations 
that use the same instruction set, this is generally never a good idea. In 
the present case though, since the assembly is fast but not the matrix 
solve, I would presume it is more a question of memory lane issues than 
anything else. Your CPU might be really memory-bandwith bound.


On Wednesday, November 15, 2023 at 11:39:59 a.m. UTC-5 Wolfgang Bangerth 
wrote:

>
>
> On 11/15/23 04:09, Abbas Ballout wrote:
> > 
> > If I run mpirun -np2 the assemble times are 25.8 seconds and the MUMPS 
> > solve times are 51.7 seconds.
> > If I run mpirun --cpu-set 0-1 -np 2, the assemble times are 26 seconds 
> > (unchanged) but the solve time are at 94.9 seconds!
> > Is this normal and expected?
>
> What happens if you use `--cpu-set 0,2` or other combinations?
>
> Cores have memory channels that they often share with other cores. I 
> wonder whether, for example, cores 0 and 1 share a memory channel and 
> consequently step on each other's toes during the direct solve (which is 
> memory bound). Or they share SIMD execution units. It would be 
> interesting to see what happens if you choose other sets of cores to use.
>
> Best
> W.
>

-- 
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/d4dfee09-df51-4f87-90ad-71b1cd7eea52n%40googlegroups.com.

Re: [deal.II] Raviart-Thomas elements on shells in 3D

[blais...@gmail.com]

If you need any help, feel free to reach out to the deal.II community, we 
are always glad to help


On Sunday, November 5, 2023 at 10:37:42 a.m. UTC-5 M. Bakry wrote:

> Dear Wolfgang,
>
> thanks very much for your answer. I think I will give it a try when I 
> find some time. Non-C1 manifolds are not an issue in the framework of the 
> BEMs. One can, for example, take a look at this reference 
> .
>
> Best regards,
>
> M.
>
> Le sam. 4 nov. 2023 à 03:45, Wolfgang Bangerth  a 
> écrit :
>
>> On 11/3/23 15:06, M. Bakry wrote:
>> > - it seems that the Piola transform is implemented for the 
>> 'codimension=1' 
>> > case (according to the templatization). Could codim=1 RT elements be 
>> > implemented by computing the RT on the reference quad then by applying 
>> the 
>> > corresponding Piola transform ?
>>
>> Marc -- quite possibly. The implementation of the RT element predates the 
>> codimension-1 functionality by several years, and I suspect that the 
>> major 
>> issue is that nobody has taken the time to convert the implementation to 
>> support surfaces.
>>
>> I will note that unless you have a C^1 manifold description -- for 
>> example if 
>> you try to describe a surface by using bilinear quads without using a 
>> manifold 
>> description -- then the normal vectors from adjacent cells are not going 
>> to 
>> point in the same direction (more precisely, they will be tangential to 
>> the 
>> cell, but not to the underlying manifold). In that case, you'll end up 
>> with a 
>> non-conforming RT space because the normal component of the finite 
>> element 
>> field is not continuous across cell interfaces.
>>
>> 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 a topic in the 
>> Google Groups "deal.II User Group" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/dealii/6Z8jBTShIq8/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/5b4695d4-b010-8591-135b-303cd6d27dc7%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/fb6f1fc5-676d-41b2-a143-2ae7bcffb4d2n%40googlegroups.com.

Re: [deal.II] In example 40, the results are significantly different between the first-order and second-order finite element meshes

[blais...@gmail.com]

Changing to Fe1 really alters the solution, so consequently the kelly error 
estimator will also give you a different error estimation and thus a 
different mesh adaptation.
If your mesh adaptation is based on an error estimator, altering the finite 
element interpolation order will alter the solution and thus alter the mesh 
adaptation process.


On Monday, November 6, 2023 at 9:13:31 p.m. UTC-5 ztdep...@gmail.com wrote:

>
> The default setting is  'fe(2)" , we can clearly see a refined region in 
>  the resulting mesh. While after i changed it to "fe(1)", we cann't see 
> this region.  
> This is what i wnat to know .
> ztdepyahoo
> ztdep...@gmail.com
>
> 
>  
>  Replied Message  
> From Wolfgang Bangerth 
> Date 11/7/2023 02:59 
> To  
> Subject Re: [deal.II] In example 40, the results are significantly 
> different between the first-order and second-order finite element meshes 
> On 11/6/23 03:12, ztdep...@gmail.com wrote:
>
> **
>
> the adaptivited mesh are very diffent as shown in attachments.
>
>
> @ztdep:
> We don't actually know what you are asking: Your post has no question. We 
> also 
> don't know what it is you did: The post doesn't show how you modified 
> step-40. 
> Finally, you do not say why you think that the result is wrong or 
> surprising: 
> You just show a picture, but for all we know this may be correct.
>
> Please spend a bit of thought in formulating questions in such a way that 
> it 
> is clear what you are asking, why you are asking it, and what is behind 
> the 
> question you are asking.
>
> 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 a topic in the 
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/dealii/VcsXMXhl_YQ/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/e17928b7-f1d0-e5f2-83b9-872ba95e492a%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/dff0c78c-7b66-4fd5-8d08-13b6b6f77efen%40googlegroups.com.

[deal.II] Two fully-funded open PhD positions at Polytechnique Montréal

[blais...@gmail.com]

Dear all,
I hope you are well.
We have three fully-funded PhD positions open in my group that we are 
aiming to fill for the Summer 2024 or Fall 2025 semester. They all concern 
the computer-assisted design of sustainable chemical reactors. This 
concerns reactors which use alternative energy vectors such centrifugal 
forces, ultrasound and microwaves.

We are located at Polytechnique Montréal, an engineering university within 
the great city of Montréal, Canada.

We are looking for candidates with good work ethics, a good interest in 
computational fluid dynamics and with the will to learn how to program and 
work as a team in a complex open-source software (Lethe) which is fully 
based on deal.II. We provide a safe, inclusive and open work environment. 
All positions are fully funded with no teaching requirements.

If you are interested, feel free to write me at bruno.bl...@polymtl.ca
If you are looking for a post-doc and you find the topic highly interesting 
and relevant to you, please feel free to write me also!

Best!
Bruno

-- 
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/9005584e-3246-4df7-aaf2-1ee03ebc0b75n%40googlegroups.com.

[deal.II] Re: UMFPACK Proble

[blais...@gmail.com]

It seems your deal.II was configured without UMFPACK.
Can you give us more information about which operating system you are using 
and under which conditions you are installing the library? This would 
greatly help us helping you debug.
Most likely you will need to reinstall deal.II with UMFPACK enabled. 


On Tuesday, September 26, 2023 at 12:51:15 a.m. UTC-4 zebhu...@gmail.com 
wrote:

> Hello everyone  I am currently  using  Deal II 9.5.1 when i try to run 
> Step-57 with cmake . get the error  '' cmake
> CMake Error at CMakeLists.txt:41 (message):
>   
>
>   Error! This tutorial requires a deal.II library that was configured with
>   the following options:
>
>   DEAL_II_WITH_UMFPACK = ON
>
>   However, the deal.II library found at /home/hussan/deal was configured 
> with
>   these options:
>
>   DEAL_II_WITH_UMFPACK = OFF
>
>   This conflicts with the requirements.
>
>
> -- Configuring incomplete, errors occurred!
> See also "/home/hussan/deal/examples/step-57/CMakeFiles/CMakeOutput.log".
> How can fix it 
>
>

-- 
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/34ff957a-b3af-4d5e-90ad-81eb693715b7n%40googlegroups.com.

[deal.II] Re: 2D circular mesh extrusion

[blais...@gmail.com]

Dear Hadi,
The Lethe code to generate all of these cylinders is fully available only. 
Might as well just reuse it :)
Everything starts here:
https://github.com/lethe-cfd/lethe/blob/master/source/core/grids.cc#L162

This should help you reproduce these kind of grids



On Thursday, September 14, 2023 at 11:45:51 a.m. UTC-4 hadimor...@gmail.com 
wrote:

> Hi,
> I hope you-all are doing okay. Btw I'm new to deal.ii and C++. Actually 
> I'm trying to generate 3D cylinder-shaped grid, fully structured hex mesh 
> as depicted in lethe documentation (attached to post). It seems that 
> refining a 3D hyper_cube would produce the target grids. So I successfully 
> generated 2D mesh which shaped as a circular surface (attached to post). 
> Then tried out extruding it, but it comes up that refined mesh is not 
> allowed to get extruded, according to deal.ii manual. I'm also a bit 
> confused about setting multiple manifolds to specific faces of the grid. 
> Honestly I tried a lot, but was not so successful. I'm gonna attach target 
> mesh images (4 different mesh types) and my 2D generated meshes. If anyone 
> could provide any help to reach target 3D meshes, it would be greatly 
> appreciated. 
> Thank you
>
> *grids in lethe documentation:*
> [image: lethe.PNG]
>
> *And here are 2D meshes I generated:*
>
>
>

-- 
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/a34ae346-789d-4e11-9c6d-cb6eeac3fa46n%40googlegroups.com.

[deal.II] Re: prmindent — Indent and format PRM files

[blais...@gmail.com]

+1 Paul, god is this script fun


On Thursday, August 10, 2023 at 7:18:48 p.m. UTC-4 Paul A. Patience wrote:

> Hello everyone,
>
> Last year I wrote a script to indent PRM files [1] in the Lethe project 
> [2]. You may find it useful.
>
> It can be used to recursively indent all PRM files in place in the current 
> directory using find [3].
>
> Best regards,
> Paul
>
> [1]: https://git.sr.ht/~paulapatience/prmindent
> [2]: 
> https://github.com/lethe-cfd/lethe/blob/master/contrib/utilities/prmindent
> [3]: 
> https://github.com/lethe-cfd/lethe/blob/241dad817bfc1fe8d58433f3cd1b098220d2/contrib/utilities/pre-commit.sh#L10
>

-- 
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/5ef1887f-f112-433d-be2e-59862b85b403n%40googlegroups.com.

Re: [deal.II] Question about how to get the Stiffness matrix partial derivative with respect to density

[blais...@gmail.com]

Dear Lance,
It would be easier if you posted the PDE you wish to solve and it's weak 
form. This would enable us to help you write the Jacobian for it.
Currently, it is difficult to fully understand what you are trying to 
achieve.
Best
Bruno

On Monday, July 24, 2023 at 4:13:21 p.m. UTC-4 dim...@gmail.com wrote:

> Hello Wolfgang,
>
> thanks for your reply.
>
> Currently,I would like to get the sensitivity by using gradient of 
> objective function with respect to density.
>
> The Objective function is a vector of movement which is calculated from 
> Ax=b.
>
> J=|x|norm1 is the objective function.
> dJ(x,Θ)/dΘ is the gradient that we will obtain in the end.
>
> We use adjoint method written in previous emails to calculate dJ(x,Θ)/dΘ.
>
> Best regards
> Lance
>
>
>
>
> Wolfgang Bangerth  于 2023年7月24日周一 21:49写道：
>
>> On 7/24/23 11:24, Lance Zhang wrote:
>> > 
>> > One moire question,how could I get  ∂A(θ)/∂θx,because I did not find 
>> any 
>> > information about density vector like  θ=[θ1,θ2,...,θm],may I know if I 
>> have 
>> > to set density vector value in this finite element?
>>
>> Lance -- I have no idea. I don't know the program, but looking at it, I 
>> see no 
>> mention of the word "density" anywhere. Apparently, the person who wrote 
>> the 
>> program implemented an equation in which density does not appear. If you 
>> want 
>> that the density is part of the formulation, you should first write down 
>> what 
>> the specific problem is you want to solve. We can't know what it is you 
>> want 
>> to do. You should then compare what you want to do with what the existing 
>> program does, and change it so that it matches to what you want it 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 a topic in the 
>> Google Groups "deal.II User Group" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/dealii/5IN4HUV1UhY/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/8819fb69-2fc9-a80c-d37d-a45411d0a89b%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/a7dd3648-4eac-47b4-acf3-eab6180aafd0n%40googlegroups.com.

Re: [deal.II] Does deal.ll support import grid from openfoam solver

[blais...@gmail.com]

It is maybe unrelated, but as far as I remember, OpenFOAM supports mesh 
adaptivity. It is maybe not as efficient (and does not include dynamic load 
balancing) like deal.II does, but I would first start with that.
Otherwise, you would need to go through the VTK file format or write your 
own openfoam reader for deal.II. I would suggest using VTK as an 
"interface" format.



On Saturday, July 15, 2023 at 8:18:31 a.m. UTC-4 vachanpo...@gmail.com 
wrote:

> I don't know about a direct technique, but you can first use foamToVTK to 
> convert foam mesh to vtk and then import vtk in dealii.
>
> Vachan
>
> On Sat, 15 Jul, 2023, 16:47 ztdep...@gmail.com,  
> wrote:
>
>> I want to couple the mesh adaptivity off deal.ll with openfoam solver. 
>> Could you please give me some suggestions.
>>
>> -- 
>> 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+un...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/dealii/86025b56-5496-4be7-8d03-c2b01acbe13cn%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/cfafab66-a67d-4cce-8be2-3267a5904d1dn%40googlegroups.com.

[deal.II] Re: Convergence failure in penalty method implementation

[blais...@gmail.com]

In addition to Wolfgang's answer. Here are some suggestions.

1. You system is not symmetric. Consequently, it is not a viable idea to 
use the CG linear solver 
(see https://en.wikipedia.org/wiki/Conjugate_gradient_method). As 
suggested, using something like GMRES would be a better idea for your case.
2. Be careful about the preconditioner  you use. Something like ILU, which 
is pretty blackbox, could do a good job for your problem (most likely). 
Increasing the fill level will increase the robustness, but make the solver 
more demanding.
3. If you wish to be able to continue your simulation when such a bug 
occur, you can catch the exception thrown by the linear solver. An example 
of this is done 
here: 
https://github.com/lethe-cfd/lethe/blob/master/source/solvers/gls_navier_stokes.cc#L1325
In essence, what we do is catch the exception and increase the fill level. 
The code to achieve this would look something like this:
try
{
  TrilinosWrappers::SolverGMRES solver(solver_control,
   solver_parameters);

solver.solve(system_matrix, solution, rhs, preconditioner;
}
  catch (std::exception )
{
Do something if convergence has failed. 
}


Best
Bruno


On Tuesday, July 18, 2023 at 2:44:54 a.m. UTC-4 sabya...@gmail.com wrote:

> Hello, 
>
> I have come up with a solution, although there may be other ones using 
> iterative solvers. I changed the solver to SparseDirectMUMPS (from tutorial 
> 62). It seems to have stopped generating the error.  Note that my stiffness 
> matrix is not symmetric ( system_matrix.is_symmetric()  is returning 0 ). 
> The modified lines are below: 
>
> --
> SolverControl solver_control(100, 1e-3*system_rhs.l2_norm());
> PETScWrappers::SparseDirectMUMPS solver(solver_control, mpi_communicator); 
> solver.solve(system_matrix, distributed_incremental_solution, system_rhs);
> --
>
> Best, 
> Sabyasachi 
> On Thursday, July 13, 2023 at 6:33:09 PM UTC+5:30 sabyasachi chatterjee 
> wrote:
>
>> I just wanted to correct one small thing. What I mean by relative error 
>> before is the residual norm, which is a relative number. 
>>
>> On Thursday, July 13, 2023 at 12:57:23 PM UTC+5:30 sabyasachi chatterjee 
>> wrote:
>>
>>> Hello, 
>>>
>>> I am trying to solve a nonlinear contact problem using penalty method. 
>>> The tangent stiffness matrix is of the form  K_e + c * K_p, where K_e and 
>>> K_p are the elastic and penalty contributions and c is the penalty 
>>> parameter, which is a large number (in the order of 10^2 to 10^3 in our 
>>> case). The part of the problem that carries out the linear solve for the 
>>> incremental displacement  using Newton Raphson method is below: 
>>>
>>>
>>> 
>>> PETScWrappers::MPI::Vector distributed_incremental_solution(
>>>   locally_owned_dofs, mpi_communicator);
>>> distributed_incremental_solution = incremental_solution;
>>>
>>> SolverControl solver_control(2, 1e-5); 
>>> PETScWrappers::SolverCG solver(solver_control, mpi_communicator);
>>> PETScWrappers::PreconditionBlockJacobi preconditioner(system_matrix);
>>>
>>> solver.solve(system_matrix,
>>>  distributed_incremental_solution,
>>>  system_rhs,preconditioner);
>>>
>>> incremental_solution = distributed_incremental_solution;
>>>
>>> hanging_node_constraints.distribute(incremental_solution);
>>> solution.add(1.0,incremental_solution); 
>>>
>>> 
>>>
>>> I receive the following error upon running the code: 
>>> --
>>> Iterative method reported convergence failure in step 33. The residual
>>> in the last step was 0.000778898.
>>>
>>> This error message can indicate that you have simply not allowed a
>>> sufficiently large number of iterations for your iterative solver to
>>> converge. This often happens when you increase the size of your
>>> problem. In such cases, the last residual will likely still be very
>>> small, and you can make the error go away by increasing the allowed
>>> number of iterations when setting up the SolverControl object that
>>> determines the maximal number of iterations you allow.
>>>
>>> The other situation where this error may occur is when your matrix is
>>> not invertible (e.g., your matrix has a null-space), or if you try to
>>> apply the wrong solver to a matrix (e.g., using CG for a matrix that
>>> is not symmetric or not positive definite). In these cases, the
>>> residual in the last iteration is likely going to be large.
>>> ---
>>>
>>> For my problem, I don't require a relative error of the order of say 
>>> 10^(-12) as is often used in the tutorials and a relative error of 10^(-4) 
>>> probably should also work. I increased the relative error to 10^(-4) and 
>>> 

Re: [deal.II] Re: Tips on writing "versatile" assembly function

[blais...@gmail.com]

Dear Corbin,
I mostly used callgrind to identify bottlenecks.
Currently, our matrix assembly and RHS assembly codes use virtualization at 
the cell level. I think this is a very adequate equilibrium. We keep all 
the flexibility, but we have not seen a drop in performance. We use the 
WorkStream paradigm and have scratch / copy data structures.

Hope that helps!
Best
Bruno


On Sunday, June 11, 2023 at 2:41:08 PM UTC-4 corbin@gmail.com wrote:

> Hello everyone, 
>
> I"m encountering a similar question for large 3D incompressible fluid 
> solver with many assembly options (which I implement via inheritance). I'd 
> like to investigate how much class/templated inheritance plays a role in 
> performance---Bruno, how do you go about profiling something like this as 
> you suggest (without having to implement an entirely new class free of 
> inheritance for comparison)?
>
> Thank you,
> Corbin
>
> On Tuesday, January 5, 2021 at 6:33:11 PM UTC-5 Doug Shi-Dong wrote:
>
>> That's interesting. Seems like it was more about inlining than branch 
>> prediction. Surprising how much difference it made.
>>
>> On Tuesday, January 5, 2021 at 6:18:38 PM UTC-5 Timo Heister wrote:
>>
>>> What I forgot to say: 
>>> We used to have something like 
>>>
>>> if (use_anisotropic_viscosity==true) 
>>> cell(i,j) += viscosity_tensor *  
>>> else 
>>> cell(i,j) += viscosity_constant *  
>>>
>>> and improved the performance by making two separate assemblers (note 
>>> that there is no function call/vtable lookup here, just an "if"). I 
>>> don't remember how big the difference was, so I went back and found 
>>> the PR: 
>>> https://github.com/geodynamics/aspect/pull/2139 
>>> Rene claims 25% fewer instructions. 
>>>
>>>
>>>
>>> On Tue, Jan 5, 2021 at 4:48 PM blais...@gmail.com  
>>> wrote: 
>>> > 
>>> > Hi Timo, 
>>> > 
>>> > I understand. It makes a lot of sense. 
>>> > Thanks! 
>>> > Bruno 
>>> > 
>>> > On Tuesday, January 5, 2021 at 4:34:19 p.m. UTC-5 Timo Heister wrote: 
>>> >> 
>>> >> Hi Bruno, 
>>> >> 
>>> >> We mitigate the performance problem by making the decision per cell 
>>> in ASPECT: 
>>> >> We have a set of "assemblers" that are executed one after each other 
>>> >> per cell. This means the vtable access cost is small compared to the 
>>> >> actual work. 
>>> >> See 
>>> >> 
>>> https://github.com/geodynamics/aspect/blob/b9add5f53172aac18bdbb19d14ca266e88c491dd/include/aspect/simulator/assemblers/interface.h#L493-L515
>>>  
>>> >> 
>>> >> On Tue, Jan 5, 2021 at 4:28 PM blais...@gmail.com  
>>> wrote: 
>>> >> > 
>>> >> > Bruno, 
>>> >> > 
>>> >> > Thanks, you are right. As always, measure first and then optimize 
>>> after. No point in optimising stuff that costs nothing... 
>>> >> > 
>>> >> > 
>>> >> > On Tuesday, January 5, 2021 at 3:15:06 p.m. UTC-5 
>>> bruno.t...@gmail.com wrote: 
>>> >> >> 
>>> >> >> Bruno, 
>>> >> >> 
>>> >> >> If you are worry about the cost of looking up though the vtable, I 
>>> think that you are stuck using template. So either use 2 or 3 and CRTP. But 
>>> first of all, I think that you should profile your code and verify that 
>>> this is a problem. There is no point in spending time refactoring your 
>>> code, if your are going to gain less than 1%... 
>>> >> >> 
>>> >> >> Best, 
>>> >> >> 
>>> >> >> Bruno 
>>> >> >> 
>>> >> >> On Monday, January 4, 2021 at 3:31:45 PM UTC-5 blais...@gmail.com 
>>> wrote: 
>>> >> >>> 
>>> >> >>> Dear all, 
>>> >> >>> I wish you all an happy new year! 
>>> >> >>> 
>>> >> >>> One problem we always end up facing with FEM problems is that, as 
>>> program grow, more and more features are added to the equations. This leads 
>>> to multiple variation of the same equations (for example, Navier-Stokes 
>>> with Newtonian and non-Newtonian viscosity, etc.). In turn, this leads to 
>>> assembly functions for the non-linear systems of equations which bran

[deal.II] Re: Using particle class for a collection of beams

[blais...@gmail.com]

Dear Vinayak,
The particle class is very flexible. You can see it as a Lagrangian 
container of information for whatever you may need to store information 
for. I don't foresee any challenges with your approach except if you need 
to maintain some sort of connectivity between the particles. If you do so, 
it will require an external data structure, since particles can only store 
double properties (e.g. mass, density, etc.).
We use particles extensively in our code to model granular flows (e.g.):
https://www.youtube.com/watch?v=qxO4MD_zg2w
https://www.youtube.com/watch?v=v32ZqxO2X98

On Wednesday, May 24, 2023 at 4:45:55 a.m. UTC-4 vinay...@gmail.com wrote:

> Dear deal.II community,
>
> I am exploring the Particle class to simulate a collection of beams (which 
> may or may not be in contact with each other). What i have imagined till 
> now is to have a background grid with "particles" (imagine beams) with 
> properties of their own. The properties of these particles will contain 
> information about the beam - for eg. centreline, material, radius, etc. In 
> particular, i wish to generate the centreline positions using the 
> triangulation class.
>
> Then after setting such up a system, i intend to use it for solving for 
> some of the "properties" of these particles - for eg. the deformed 
> centreline position. I also wish to use particle-level refinement for some 
> selected particles (here beams). Therefore, different "particles" (imagine 
> beams) will have different number of properties.
>
> It would really help me if someone could comment on the viability of my 
> idea to use the Particle class for such a problem. 
>
> Thanks
> Vinayak
>  
>

-- 
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/d408996a-afab-45bc-a2c7-6fe98a327d5cn%40googlegroups.com.

Re: [deal.II] Finding AVX instructions always fails at cmake configure step

[blais...@gmail.com]

Dear Martin,
Now I feel kind off dumb. This is what I was doing to compile an AVX test 
on the side, did not think to include it this way in the CMAKE procedure.
Thanks! Worked very well and now it detects my AVX2 instructions :).
Best
Bruno


On Thursday, May 4, 2023 at 8:57:43 a.m. UTC-4 Martin Kronbichler wrote:

> Dear Bruno,
>
> You need to specify appropriate CXX flags. For example, I always use 
>   -D CMAKE_CXX_FLAGS="-march=native"
> on my local machines (that run the code I'm compiling) or 
>   -D CMAKE_CXX_FLAGS="-march=icelake-server"
> on clusters to be sure the right code gets generated. For example GCC 
> lists the available architectures to specify here:
>
> https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
>
> Best,
> Martin
>
>
> On 04.05.23 14:52, blais...@gmail.com wrote:
>
> Dear all,  
> Hope you are well.
> I have tried a few ways to enable AVX instructions (which I think my 12th 
> Gen Intel(R) Core(TM) i9-12900K) should support, yet I am always unable 
> to do so. At the Cmake configuration step, the AVX steps all fails whereas 
> the SSE ones succeed.
> How can I remedy this issue?
> Best
> Bruno
>
>
> -- 
> 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+un...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/31bda9f7-5312-4674-b235-5e208716db86n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/dealii/31bda9f7-5312-4674-b235-5e208716db86n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>

-- 
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/40c91033-6b84-42df-9f9e-587f097fb484n%40googlegroups.com.

[deal.II] Finding AVX instructions always fails at cmake configure step

[blais...@gmail.com]

Dear all, 
Hope you are well.
I have tried a few ways to enable AVX instructions (which I think my 12th 
Gen Intel(R) Core(TM) i9-12900K) should support, yet I am always unable to 
do so. At the Cmake configuration step, the AVX steps all fails whereas the 
SSE ones succeed.
How can I remedy this issue?
Best
Bruno


-- 
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/31bda9f7-5312-4674-b235-5e208716db86n%40googlegroups.com.

[deal.II] Re: Trouble installing p4est from candi M1 mac

[blais...@gmail.com]

What I would suggest is to not use GCC, but instead use the clang compiler 
native with the Mac M1.
At least this is how I did it on my apple M1 macbook pro computer


On Thursday, April 6, 2023 at 6:25:13 a.m. UTC-4 malve...@gmail.com wrote:

> Good afternoon.
> I’m truly sorry to bother you, but I’ve spent a lot of time trying to fix 
> this problem, without any success.
> I’m trying to install dealii on my M1 macbook air with MacOs Ventura.
> Ive been following the guide on 
> https://github.com/dealii/dealii/wiki/Apple-ARM-M1-OSX
>
> I installed brew
> I verified I have mac developer tools updated
> Using brew I installed cmake and openmpi.
> Using brew, with much more effort and not complete certainty of success, I 
> installed gcc11.
>
> I cloned candi git repo.
> I set the following env variables, to use clang instead of gcc11:
>
> *export CC=mpicc; export CXX=mpicxx; export FC=mpifort; export FF=mpifort; 
> \  OMPI_CC=clang; export OMPI_CXX=clang++; export OMPI_FC=gfortran-1*
> I began installing the packages together but had troubles.
>
> So I proceeded doing them one by one.
> hdf5 went fine
> But p4est exits with the following error:
>
>
>
>
>
>
>
> *Build FAST version in 
> /Users/matteom/dealii-candi/tmp/build/p4est-2.3.2/FAST/Users/##/dealii-candi/tmp/unpack/p4est-2.3.2/configure:
>  
> line 4056: test: argument expectedconfigure: error: in 
> `/Users/##/dealii-candi/tmp/build/p4est-2.3.2/FAST':configure: error: 
> Fortran 77 compiler cannot create executablesSee `config.log' for more 
> detailsError: Error in configure*
> Note: I even tried to switch to Master branch, but nothing changed.
>
>
> Do you have any clue what I could try next?
>
> Thanks for your cooperation.
> Best wishes,
> Matteo Malvestiti
>
>

-- 
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/24357a2e-1b43-4ed3-b841-19760e650d96n%40googlegroups.com.

[deal.II] Re: Fully distributed triangulation with GMSH

[blais...@gmail.com]

Dear Kumar,

You can monitor the processes using your OS to verify that.
If you are loading a relatively large triangulation, this will be very 
apparent since the memory footprint of one process will be significantly 
larger. Even a quick "top" will enable you to see this.
Best
Bruno

On Wednesday, March 15, 2023 at 5:22:33 p.m. UTC-4 kumar.sau...@gmail.com 
wrote:

> HI Peter,
>
> Thanks a lot. It seems to work. If I am understanding it correctly, having 
> group size = MPI ranks, means that only proc 0 is reading the data and 
> distributing it. Am I correct? 
>
> Is it possible to verify the size of elements / memory size after the file 
> is read and before the partition to actually verify that only proc 0 is 
> reading and storing before partitioning?
>
> Thanks,
> Kumar Saurabh
> On Tuesday, March 14, 2023 at 11:33:04 PM UTC-7 peterr...@gmail.com wrote:
>
>> Hi Kumar,
>>
>> take a look at 
>> https://www.dealii.org/developer/doxygen/deal.II/namespaceTriangulationDescription_1_1Utilities.html#aefc3e841bcfd37714a07d04e42c8ffca
>> .
>>
>> Hope this helps,
>> Peter
>>
>> On Wednesday, 15 March 2023 at 01:44:17 UTC+1 kumar.sau...@gmail.com 
>> wrote:
>>
>>> Hi, 
>>>
>>> I am trying to perform the mesh partition using the mesh generated from 
>>> GMSH. The generated mesh is quite big with around 500K elements. 
>>>
>>> I am new to deal.ii. But I get the impression that the 
>>> parallel::distributed::Triangulation works only from the 
>>> quadrilateral/hexahedral meshes and uses p4est backend.
>>>
>>> I tried GridTools::partition_triangulation which tends to repeat the 
>>> elements on all processor. This is not ideal as the number of elements is 
>>> too large.
>>>
>>> I want to ask if I can use parallel::fullydistributed::Triangulation to 
>>> partition the tetrahedrals without repeating on all the processors. If so, 
>>> is there any examples for the same. All the examples I saw tends to work 
>>> for Hypercube type of meshes.
>>>
>>> Thanks,
>>> Kumar Saurabh
>>>
>>

-- 
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/deb475db-0b78-4afd-84f1-c766f1459792n%40googlegroups.com.

[deal.II] Re: Solving navier stokes equation gives no convergence

[blais...@gmail.com]

Can you tell us a bit more about what you have tried? For example, in the 
limit of low Re (say Re=0.1 or Re=1) does your non-linear solver converge? 
Have you tried making a manufactured solution to get your convergence order 
to see if everything is all fine?
RE=200 can be quite heavy for straight-up Newton solver. The linear-search 
generally really helps for cases when you are trying to get a steady-state 
solution.



On Thursday, January 26, 2023 at 11:15:11 a.m. UTC-5 ggg wrote:

> I already solved the stokes equation and was trying to generalize it to 
> solve the steady NS equation.
>
> I saw the step-57 tutorial but I have a mesh from file (while the tutorial 
> create in dealii and refine, things that I'm not allowed to do) and also 
> uses line search algorithm, which also can't perform.
>
> The general structure of the program is: setup vectors, sparsity and 
> matrices (pressure and  velocity), newton iteration where first solve the 
> stokes problem to get the initial guess for newton (Re will always be < 200 
> in my test case, for now), and the start to iterate, at each iteration:
> - assemble the system
> - solve the linearized system
>
> I know the stokes solution is correct. But for the NS solution I have the 
> residual decreasing at first 2 steps and then increasing, leading to 
> divergence (around step 16 dealii fires the no convergence). The assembly 
> is the same as the tutorial at step-57.
>
> It's becoming really frustrating, so if anyone can help I really 
> appreciate. I give you the code in case my explanation wasn't clear.
>
>
> https://drive.google.com/drive/folders/1igXMgWq2g6UPRxaRE9Ot1jU5L_eUW9Wk?usp=sharing
>
> PS: the mesh is fine since already used for previous problems.
>
>
>
>
>
>
>

-- 
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/bc4cde03-55a1-45e6-bb1a-e9cff425585en%40googlegroups.com.

Re: [deal.II] Assemble system slowing down the program

[blais...@gmail.com]

There might be many things that can be done to improve the speed of this 
function. You can ask yourselve the following question as guidance:
- Does the function allocate memory?
- Could it be inlined?
- Are you calling the function inside the DOF loops or inside the 
quadrature loop?

Then I would time the function to measure if this is actually the real 
culprit or if it could be something else.
If you copy/paste the content of your assembly code and the function, I 
would be glad to give it a look (and I am sure others here will help you 
too).


On Saturday, January 7, 2023 at 12:02:13 a.m. UTC-5 
ce21...@smail.iitm.ac.in wrote:

> Sorry for the confusion. I think I made a mistake while writing the first 
> email.
>
> H_plus is being called in Assemble_damage and not assemble_elastic. It 
> uses elastic solution, cell and gauss point to evaluate strain at a gauss 
> point. Then some quantity is evaluated based on the strain.
>
> Similarly I have another function damage_gauss which is being called in 
> assemble_elastic that evaluates damage at a gauss point using the damage 
> solution, cell and gauss point.
>
> Wasim Niyaz
> Research scholar
> CE Dept.
> IITM
>
> On Sat, 7 Jan, 2023, 10:15 am Wasim Niyaz Munshi ce21d400, <
> ce21...@smail.iitm.ac.in> wrote:
>
>> I use it to evaluate strain at Gauss points. Then, i evaluate some 
>> quantity which is a function of this strain.
>>
>> Wasim Niyaz
>> Research scholar
>> CE Dept.
>> IITM
>>
>> On Sat, 7 Jan, 2023, 3:09 am Wolfgang Bangerth,  
>> wrote:
>>
>>> On 1/6/23 13:53, Wasim Niyaz Munshi ce21d400 wrote:
>>> > I am using 65536 elements. For step-8 the assembly takes very less 
>>> time 
>>> > (around 0.15second) while for my assemble_elastic, it takes around 5 
>>> seconds. 
>>> > The only difference between my assemble_elastic function and the 
>>> assemble 
>>> > function of step-8 is that for each Gauss point, I additionally  call 
>>> a 
>>> > function(H_plus) that takes the laplace solution, the current cell and 
>>> Gauss 
>>> > point as input and evaluates some quantity using this information.
>>> > The H_plus function is called 4*65536 times but the function is very 
>>> simple.
>>> > My doubt is whether such a huge increase in cost (from 0.15 sec to 5 
>>> sec) is 
>>> > expected for this problem or is there something that I am doing that 
>>> is 
>>> > increasing the cost so much.
>>>
>>> Wasim, the question is what you do with "the laplace solution, the 
>>> current 
>>> cell and Gauss point". If you show us what H_plus does, we may be able 
>>> to advise.
>>>
>>> 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 a topic in the 
>>> Google Groups "deal.II User Group" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/dealii/-6ndTW_k5fQ/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/895a079c-2b85-b14f-94ee-b4b78336884d%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/2684682a-932e-4408-982d-0016d0955296n%40googlegroups.com.

[deal.II] Control over the "valence" of p4est distributed meshes

[blais...@gmail.com]

Dear all,
I hope you are well.

I know that P4est as a partitioner has limitations compared to other 
approaches like Metis or Scotch. However, I was wondering if there was 
anyway to penalize the partitioner in order to generate the smaller valence 
that is possible? Sometimes we end up with interfaces between processors 
that are substantially big (or islands of a few cells). The issue is that 
for our particle code, this generates a ton of Ghost particles and these 
particles generate additional cost (collisions become significantly more 
expensive to calculate because we cannot apply newton's third law for a 
collision. The calculation becomes essentially duplicated). 

I was wondering if there was any ways to "force" or ensure that the 
interfaces between subdomains remained relatively well-posed?

Thank you very much!
Bruno

-- 
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/08ba5731-6692-439b-8921-3dc92631f8d6n%40googlegroups.com.

[deal.II] Re: What's the best strategy to speed up assembly?

[blais...@gmail.com]

I am a bit surprised that your assembly is really 100x more expensive than 
your linear solver.
Maybe your assembly code is not optimized? 
For example, I try to avoid doing as much work as possible during the 
double loop over DOFs which is the inner most loop. Sometimes 
pre-calculating things in the outer loop really speeds-up the calculation. 
This also depends on the polynomials you are using for interpolation. If 
you are using high-order polynomials, I think this is where you will reap 
the benefits of Matrix free significantly.

Feel free to ask more questions :)!
Best
Bruno


On Thursday, December 8, 2022 at 11:10:51 a.m. UTC-5 kmsc...@gmail.com 
wrote:

> Hej, 
>
> I've written here before and hope I don't misuse the mailing list - 
> however I've been looking a bit in the documentation and here and haven't 
> really found a conclusive answer.
>
> I am aiming to solve a nonlinear hyperbolic transport equation. For the 
> sake of the argument, let's say it reads
>
> mu \cdot \nabla f(x) = - f(x)^2 - 2*b(x)*f(x) - a(x)
>
> this is, of course, a Riccati equation (up to signs, possibly). In my 
> case, f is a complex function but this is of little relevance here. Since 
> it's a nonlinear problem I need to construct both the Jacobian and the 
> residual. For starters, I do that in each step.
>
> I've managed to implement this and even get a PETSc-parallelised version 
> to work, and am very happy. (I love deal.ii, by the way - very impressive). 
> It scales not "optimally" on my small laptop but it's still a fine speedup 
> when using MPI. So far so good.
>
> However, I want to solve my problem for many different directions vF, and 
> then extract all the solutions and do something with them. As such, my 
> problem is less that I need very large number of DOFs / huge meshes - my 
> typical mesh will be on the order of 1 unknowns, maybe 100k but not 
> millions. Rather, I want the individual solves to be as fast as possible 
> since I need to do on the order of 100-1 of them, depending on the 
> problem at hand. 
>
> I've done some layman's benchmarking of the individual "steps" (setup, 
> assembly, solve, ...) in my current version of the code. It looks as if the 
> assembly takes several orders of magnitude (~100 at least) longer than the 
> solving part.
>
> My question is now: What is the best strategy to speed up assembly, is 
> there any experience with this? I've read different approaches and am 
> confused what's promising for small-scale problems. So far I'm considering:
>
> 1) Using a matrix-free approach rather than PETSc - this seems to be a win 
> in most cases, would however consider  rewriting large parts of the code 
> and I am not sure if I will gain a lot given my small system size.
>
> 2) Only assemble the Jacobian every few steps, but the residual in every 
> step. This is probably easier to implement. I know from experience with my 
> problem that I pretty quickly land in a situation where I need only one or 
> two Newton steps to find the solution to my nonlinear equation, so there 
> saving will be small at best. 
>
> Is there anything else one can do? 
> So far I've been using MeshWorker, which is fine and understandable to be, 
> but e.g. the boundary term as used in Example 12 queries the scalar product 
> of \mu and the edge normal in each boundary element, which seems like a 
> possible slowdown - in addition to generating jumps and averages on inner 
> cell edges.
>
>  Any help is much appreciated. Sorry for the long text!
> /Kev
>

-- 
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/4977f9c9-45e8-4fc0-aed4-e6c9bd1783cfn%40googlegroups.com.

Re: [deal.II] Applying a zero constraints to cell based on material_id

[blais...@gmail.com]

Elegant solution, I like it.
Thanks!


On Monday, October 31, 2022 at 9:19:51 a.m. UTC-4 d.arnd...@gmail.com wrote:

> Bruno,
>
> I don't think we have a function that would do that already. I would just 
> loop over all (locally relevant) cells, and add the respective (locally 
> relevant) dofs to the AffineConstraints object with add_line().
>
> Best,
> Daniel
>
> On Mon, Oct 31, 2022 at 8:36 AM blais...@gmail.com  
> wrote:
>
>> Dear all, I hope you are all doing fine :)!
>>
>> I am trying to do some quick testing of something and this would require 
>> me applying a zero constraint to a set of cells which have a specific 
>> material id. I could surely do that from the weak form, but I was wondering 
>> if there was a way to do it strongly by applying a constraint like we do 
>> with boundary conditions (e.g. using VectorTools). I looked around in the 
>> documentation but I could not find anyway (but maybe I did not look 
>> carefully enough).
>>
>> Thanks!
>> Bruno
>>
>> -- 
>> 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+un...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/dealii/0605a226-d35e-4286-ad2e-13a7b1c185e9n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/dealii/0605a226-d35e-4286-ad2e-13a7b1c185e9n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/d6095dd4-4979-429a-a420-983bb2cc1561n%40googlegroups.com.

[deal.II] Applying a zero constraints to cell based on material_id

[blais...@gmail.com]

Dear all, I hope you are all doing fine :)!

I am trying to do some quick testing of something and this would require me 
applying a zero constraint to a set of cells which have a specific material 
id. I could surely do that from the weak form, but I was wondering if there 
was a way to do it strongly by applying a constraint like we do with 
boundary conditions (e.g. using VectorTools). I looked around in the 
documentation but I could not find anyway (but maybe I did not look 
carefully enough).

Thanks!
Bruno

-- 
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/0605a226-d35e-4286-ad2e-13a7b1c185e9n%40googlegroups.com.

[deal.II] Re: Using the deal.II video lectures for finite element courses

[blais...@gmail.com]

Thank you very much for pointing this reference out.
It is highly helpful and I think the community really appreciate you making 
all these efforts to not only move science forward, but teach it in a 
better fashion :)


On Thursday, August 4, 2022 at 9:47:36 p.m. UTC-4 Wolfgang Bangerth wrote:

>
> All:
> Many of you have over the years watched the video lectures I have put onto 
> Youtube (and Bilibili in China):
> https://www.math.colostate.edu/~bangerth/videos.html
>
> These videos were originally intended to allow me more flexibility in my 
> Computational Math courses that I use for more 1:1 interaction with my 
> students. Over time, of course, the number of videos has grown 
> substantially 
> beyond what one needs for a single semester, and the videos have also been 
> used by many others in their courses. But the way I teach these courses 
> has 
> also evolved over time.
>
> With a number of education researchers, we have investigated how these 
> courses 
> should be taught, and how this actually works. If you are using these 
> videos 
> to teach your own courses, you may be interested in the following 
> publication 
> where we describe our course design and its assessment:
>
>
> https://www.math.colostate.edu/~bangerth/publications/2020-learning-journals.pdf
>
> This paper has a bit of a difficult genesis story. The computational 
> sciences 
> community wasn't too interested in the paper (because mathematicians and 
> computer science folks "know how to teach best" and don't need anyone to 
> tell 
> them), and the education community wanted something more education-y than 
> just 
> a case study (a fair request). As a consequence, the paper has accumulated 
> a 
> number of sections on education theory (specifically section 2) that may 
> not 
> be of such great interest to many of you. But I hope that the rest of the 
> paper -- the course design and assessment sections -- may still be useful 
> to 
> those of you who are or are interested in teaching CS courses!
>
> Best
> Wolfgang
>
> -- 
> 
> 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/32d38422-19db-4878-b80d-29aed88ebf41n%40googlegroups.com.

[deal.II] AVX and AVX512 instruction detection

[blais...@gmail.com]

Dear all,
I hope you are well.

I was wondering if there was anything specific that had to be done to 
enable deal.II to leverage AVX and AVX512 instructions on intel processors?

By default, it seems that on my intel machine, these vectorization 
instructions are not detected, e.g.:
-- Performing Test DEAL_II_HAVE_SSE2
-- Performing Test DEAL_II_HAVE_SSE2 - Success
-- Performing Test DEAL_II_HAVE_AVX
-- Performing Test DEAL_II_HAVE_AVX - Failed
-- Performing Test DEAL_II_HAVE_AVX512
-- Performing Test DEAL_II_HAVE_AVX512 - Failed
-- Performing Test DEAL_II_HAVE_ALTIVEC
-- Performing Test DEAL_II_HAVE_ALTIVEC - Failed


However, I can see that avx  is a supported set of instruction on my 
processor by looking at /proc/cpuinfo.

Is there something I am missing that needs to be done to enable full 
support of vectorization instruction?

Best :)
Bruno

-- 
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/afbf2a90-29ac-41a2-945c-918f4517f863n%40googlegroups.com.

[deal.II] Re: Clemson Computational Math Seminar: Bruno Blais - Feb 4

[blais...@gmail.com]

You had me scared there for a moment.
Looking forward to this :)!


On Friday, March 25, 2022 at 1:15:31 p.m. UTC-4 Timo Heister wrote:

> Hi all,
>
> I am sorry for messing up the title. The talk is of course given on
> Monday by Matthias as written in the body of the email.
>
> Best,
> Timo
>
> On Fri, Mar 25, 2022 at 1:11 PM Timo Heister  wrote:
> >
> > Hi all,
> >
> > I would like to announce the following seminar talk in our Clemson
> > Computational Math seminar that is related to deal.II. If you are
> > interested, feel free to join using the zoom link below.
> >
> > Date and time: Monday, March 28 at 11:15am Eastern time
> > Speaker: Matthias Maier (Texas A University)
> > Title: Efficient parallel 3d computation of the compressible
> > Navier-Stokes equations
> >
> > Zoom link: https://clemson.zoom.us/j/96402109287
> >
> > Abstract:
> > A high-performance second-order collocation-type finite-element scheme 
> for
> > solving the compressible Navier-Stokes equations on unstructured meshes 
> is
> > presented. The method uses Strang splitting, is second-order accurate in
> > time and space, and is based on a convex limiting technique introduced by
> > Guermond et al. (SIAM J. Sci. Comput. 40, A3211-A3239, 2018). As such it 
> is
> > invariant-domain preserving, meaning, the solver maintains important
> > physical invariants and is guaranteed to be stable without the use of
> > ad-hoc tuning parameters.
> > In this talk I will introduce the discretization technique, discuss the
> > convex limiting approach and algorithmic design of the method, and 
> comment
> > on a high-performance implementation utilizing SIMD (single instruction
> > multiple data) vectorization.
> >
> > --
> > Timo Heister
> > http://www.math.clemson.edu/~heister/
>
>
>
> -- 
> Timo Heister
> http://www.math.clemson.edu/~heister/
>

-- 
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/21d139b7-d7e0-4a9c-b3d2-d0c7309b1937n%40googlegroups.com.

Re: [deal.II] Error when compiling a deal.II app using Trilinos on Apple M1

[blais...@gmail.com]

Ohh but that explains everything. In the application that I am trying to 
compile we set the standard to CXX17 hence it must be forcing the compiler 
to do so.
Everything is clear with this. Thank you so much :)!
Again, amazing work on the whole candi endeavour.


On Tuesday, March 15, 2022 at 7:42:53 p.m. UTC-4 Wolfgang Bangerth wrote:

> On 3/14/22 11:24, blais...@gmail.com wrote:
> > 
> *Users/blaisb/work/candi/trilinos-release-12-18-1/include/Tpetra_Import_def.hpp:1171:24:
>  
>
> > **error: **no member named 'bind1st' in namespace 'std'; did you mean 
> > 'boost::container::bind1st'?*
> > 
> >std::bind1st (std::equal_to (), -1));
> > 
> > *   ^*
> > 
>
> The patch to Trilinos is here:
>
>
> https://github.com/trilinos/Trilinos/commit/285bbae1720f2cb4379e43ed338dbd2a23bf8ea6
> It was committed in November of last year as part of
> https://github.com/trilinos/Trilinos/pull/9960
>
> 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/53207523-2bb2-4ed2-8393-91652ddd0911n%40googlegroups.com.

Re: [deal.II] Error when compiling a deal.II app using Trilinos on Apple M1

[blais...@gmail.com]

Still can't get it to work. It seems to be related to a specific Tpetra 
file:
"Tpetra_Import_def.hpp"
I'll try with a more recent version of Trilinos to see if this fixes thing. 
Do you think it might be that step-32 does not include this file ?


On Tuesday, March 15, 2022 at 10:55:35 a.m. UTC-4 blais...@gmail.com wrote:

> Step-32 worked. I think there was an issue with the way I set-up my dylib. 
> I'll investigate, but it seems that since I was able to run step-32 with 
> MPI, I should be ok on my side also :)
> I'll keep you informed if this pops up again.
>
>
> On Monday, March 14, 2022 at 8:57:01 p.m. UTC-4 Timo Heister wrote:
>
>> I worked on that.  
>>
>> Interestingly, I didn't see this error in my testing of ASPECT. Are 
>> you saying that a deal.II step like step-32 fails? I think we should 
>> try updating Trilinos first. 
>>
>> Do you want to try 13.2 and see if that works? If not, I will update 
>> the package in candi master when I get to it in a couple of days. 
>>
>>
>> On Mon, Mar 14, 2022, 13:25 blais...@gmail.com  
>> wrote: 
>> > 
>> > Dear all, 
>> > Hope you are well 
>> > Using the candi master branch, I succeeded in compiling deal.II using 
>> candi. Everything was smooth. I don't know who took care of that, but 
>> awesome work. 
>> > 
>> > When trying to compile an example that uses Trilinos (any), I get the 
>> following error that arise from an include in Trilinos 
>> > 
>> > 
>> Users/blaisb/work/candi/trilinos-release-12-18-1/include/Tpetra_Import_def.hpp:1171:24:
>>  
>> error: no member named 'bind1st' in namespace 'std'; did you mean 
>> 'boost::container::bind1st'? 
>> > 
>> > std::bind1st (std::equal_to (), -1)); 
>> > 
>> > ^ 
>> > 
>> > 
>> /Users/blaisb/work/candi/deal.II-master/include/deal.II/bundled/boost/container/detail/algorithm.hpp:55:24:
>>  
>> note: 'boost::container::bind1st' declared here 
>> > 
>> > inline binder1st bind1st(const Func& func, const T& arg) 
>> > 
>> > 
>> > 
>> > Is there a way around this error? Should I try to manually fix it or 
>> switch to another trilinos version? 
>> > 
>> > Thanks! 
>> > 
>> > Bruno 
>> > 
>> > 
>> > -- 
>> > 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+un...@googlegroups.com. 
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/dealii/fc6ad924-8776-4fa8-8a6f-5c96c44a0c47n%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/7f7277e9-5279-4bba-9bab-e75afb05986an%40googlegroups.com.

[deal.II] Error when compiling a deal.II app using Trilinos on Apple M1

[blais...@gmail.com]

Dear all,
Hope you are well
Using the candi master branch, I succeeded in compiling deal.II using 
candi. Everything was smooth. I don't know who took care of that, but 
awesome work.

When trying to compile an example that uses Trilinos (any), I get the 
following error that arise from an include in Trilinos

*Users/blaisb/work/candi/trilinos-release-12-18-1/include/Tpetra_Import_def.hpp:1171:24:
 
**error: **no member named 'bind1st' in namespace 'std'; did you mean 
'boost::container::bind1st'?*

   std::bind1st (std::equal_to (), -1));

*   ^*

*/Users/blaisb/work/candi/deal.II-master/include/deal.II/bundled/boost/container/detail/algorithm.hpp:55:24:
 
note: *'boost::container::bind1st' declared here

inline binder1st bind1st(const Func& func, const T& arg)



Is there a way around this error? Should I try to manually fix it or switch 
to another trilinos version?

Thanks!

Bruno


-- 
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/fc6ad924-8776-4fa8-8a6f-5c96c44a0c47n%40googlegroups.com.

[deal.II] Opening for a PhD or Post-doc position at Polytechnique Montréal

[blais...@gmail.com]

Dear all,

Are you interested in the environment and on harnessing renewable energies 
in chemical processes? Do you have a keen interest in fluid dynamics and 
computational fluid dynamics? Do you love using deal.II ? Are you 
interested in multiphase flows? 

We have a very interesting opening for a fully funded PhD or Post-Doc 
post-doc position at Polytechnique Montréal in partnership with a company 
called Pyrowave  (https://www.pyrowave.com/) that develops a new generation 
of chemical reactor that harness microwaves to carry out chemical reaction. 
A description of the position is added as a pdf with this post.
Please feel free to reach out to me by e-mail if you have any questions or 
to share within your network.

Cheers
Bruno

-- 
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/3362439b-7a8c-4ee7-91ef-7fff1c43680an%40googlegroups.com.

Re: [deal.II] Way to use the erf function with MuParser?

[blais...@gmail.com]

Awesome,
I'll make a PR for it.


On Wednesday, February 16, 2022 at 11:33:58 p.m. UTC-5 Wolfgang Bangerth 
wrote:

> On 2/16/22 20:16, blais...@gmail.com wrote:
> > 
> > It seems MuParser does not, by default, allow for the use of the error 
> > function (erf). We are solving a Stefan problem right now and I'd like 
> to be 
> > able to compare the solution to the analytical one to make a unit test 
> out of 
> > it. Regrettably, the analytical solution is an ugly beast containing an 
> error 
> > function (e.g. erf (x) )
> > It seems that muparser does not allow for the usage of erf. Would any of 
> you 
> > have an idea how i could circumvent this issue? Everything works super 
> well, 
> > but i'd like to be able to monitor the convergence and, right now, this 
> is not 
> > exactly possibly because of this erf function.
>
> Strangely, we support erfc but not erf. But it should be easy enough to 
> implement if you're willing to extend deal.II. Take a look here:
>
>
> https://github.com/dealii/dealii/blob/master/source/base/function_parser.cc#L190-L192
>
> and
>
>
> https://github.com/dealii/dealii/blob/master/source/base/mu_parser_internal.cc#L114-L118
>
> 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/3579eddb-ca46-4ecc-9efb-8525884f29a7n%40googlegroups.com.

[deal.II] Way to use the erf function with MuParser?

[blais...@gmail.com]

Dear all,
I hope you are well?
It seems MuParser does not, by default, allow for the use of the error 
function (erf). We are solving a Stefan problem right now and I'd like to 
be able to compare the solution to the analytical one to make a unit test 
out of it. Regrettably, the analytical solution is an ugly beast containing 
an error function (e.g. erf (x) )
It seems that muparser does not allow for the usage of erf. Would any of 
you have an idea how i could circumvent this issue? Everything works super 
well, but i'd like to be able to monitor the convergence and, right now, 
this is not exactly possibly because of this erf function. 

:)
Best
Bruno

-- 
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/ddd0eceb-182d-4fca-bffb-828a629ea700n%40googlegroups.com.

[deal.II] Re: Smooth particles hydrodynamic implementation in DealII

[blais...@gmail.com]

Dear Hassan,
Everything is described there:
https://arxiv.org/abs/2106.09576

The algorithm is pretty simple. For every cell, we find the list of 
possible neighbours. We define this list by looking at every cell which 
shares a vertex with a cell we are presently working with. For all 
particles, in a cell, we find all potential neighbours using this list of 
cells which are neighbours of the cell in which the particle lies. That's 
the coarse contact detection.
The finer one uses a distance function and the radius of the particles to 
identify if two particles are within potential contact distance (say 1.5 * 
the particle diameter). Then, these "fine" neighbours are stored in another 
container and are kept for as many time steps as possible (until we have 
moved the particle 0.25*diameter). This last part saves a lot of 
computational time.

The tricky part was choosing the appropriate container for these neighbours 
because in DEM you need to store the history of a contact. Consequently, 
you need a data structure that you can easily insert in and remove out of. 
That's why we went with an unordered map approach. It is maybe not optimal, 
but it really does work well right now.

On Monday, February 14, 2022 at 4:33:13 a.m. UTC-5 hassan...@gmail.com 
wrote:

> Dear Bruno
>
> That is what I am looking for. Surely its good to have them in deal.II. 
> Otherwise, could you please describe shortly the algorithm that you used to 
> do that.  
>
> Thanks, 
> Hassan
>
> On Sunday, February 13, 2022 at 6:21:42 PM UTC+3:30 blais...@gmail.com 
> wrote:
>
>> Dear Hassan,
>> There is no way to do that directly in Deal.II
>> Lethe adds two classes to achieve this using a coarse and then a fine 
>> contact detection.
>>
>> https://github.com/lethe-cfd/lethe/blob/master/include/dem/particle_particle_broad_search.h
>>
>> https://github.com/lethe-cfd/lethe/blob/master/include/dem/particle_particle_fine_search.h
>>
>> If you are interested, we could eventually try to port them to deal.II, 
>> but these are very lethe specific at the moments.
>> Otherwise, you can use these ideas to generate your contact list. These 
>> will work if you use the background mesh as your contact detection grid 
>> (which is what we do, it's quite efficient and robust).
>>
>>
>> On Saturday, February 12, 2022 at 3:59:16 a.m. UTC-5 hassan...@gmail.com 
>> wrote:
>>
>>> Dear Wolfgang and Bruno 
>>>
>>> thank you for your answers. I will study the 'lethe' code. 
>>> I want to apply constraints on linear momentum for a set of particles. 
>>> Actually, I want to build an SPH code from scratch. We are working with 
>>> a total Lagrangian formulation, so position of particles is constant. 
>>> Additionally.  we are working with just a layer of neighbor particles in 
>>> each direction. I did't understand how to find neighbor particles, I was 
>>> looking for a way to access neighbor particles, something like the one that 
>>> is used for the cell in step-68 "particle->get_surrounding_cell()".
>>>
>>> Thanks
>>> Hassan
>>>
>>> On Saturday, February 12, 2022 at 6:27:09 AM UTC+3:30 blais...@gmail.com 
>>> wrote:
>>>
>>>> If I may suggest, at that point, I would ask you what you are trying to 
>>>> specifically achieve?
>>>> If you want to build an SPH code from scratch, this is definitely 
>>>> possible to do using deal.II particle classes (esp. with the exchange and 
>>>> update ghosts functionalities), but this will require a lot of work. In 
>>>> that case, it might also be a good idea to look at an SPH code designed 
>>>> from scratch for this (e.g. DualSPHPhysics is a good one)
>>>> In our case, we built our DEM code using deal.II because
>>>> A) DEM is simpler than SPH (shorter scale interaction)
>>>> B) We wanted to couple our DEM to our CFD and deal.II was the perfect 
>>>> vehicle for that.
>>>>
>>>> It is definitely doable to build from scratch, but it will be a massive 
>>>> endeavour to make it fast.
>>>>
>>>>
>>>>
>>>> On Thursday, February 10, 2022 at 3:34:13 a.m. UTC-5 
>>>> hassan...@gmail.com wrote:
>>>>
>>>>> Dear dealII users
>>>>>
>>>>> I want to solve a series of conservation law using smooth particles 
>>>>> hydrodynamics (SPH). I am looking for a parallel solution.  could you 
>>>>> please help me to setup my code correctly.
>>>>>
>>>>> 1- The number of unknowns is 

[deal.II] Re: Clemson Computational Math Seminar: Bruno Blais - Feb 4

[blais...@gmail.com]

Pleasure was all mine.
Thanks for the invite.
I consider myself quite lucky to be part of such a vibrant, open and 
constructive community :)!


On Friday, February 11, 2022 at 4:57:39 p.m. UTC-5 Timo Heister wrote:

> Hi all,
>
> The recording of the talk is now available at
> https://www.youtube.com/watch?v=-qJfml3_HuA
>
> Thanks again, Bruno!
>
> On Mon, Jan 31, 2022 at 2:56 PM Timo Heister  wrote:
> >
> > Hi all,
> >
> > I would like to announce the following seminar talk in our Clemson
> > Computational Math seminar that is related to deal.II. If you are
> > interested, feel free to join using the zoom link below.
> >
> > Date and time: Friday, Feb 4 at 11:15am Eastern time
> > Speaker: Bruno Blais (Polytechnique Montréal)
> > Title: Lethe: Open-source FEM-based CFD and CFD-DEM models for the
> > simulation, design and optimization of chemical processes
> >
> > Zoom link: https://clemson.zoom.us/j/96402109287
> >
> > Abstract:
> > Chemical process plants generally consist of a combination of multiple
> > unit operations which all
> > have a specific purpose: separating components, facilitating a
> > chemical reaction, mixing,
> > transferring energy from one fluid to another, moving fluids. The
> > design of these operations is still
> > mostly based on design heuristics which lead to significant challenges
> > when designing new chemical
> > processes or scaling-up existing ones. These challenges are
> > exacerbated by the occurrence of
> > turbulence, the complex rheology of the fluid or the presence of
> > multiple phases such as a fluid (gas
> > or liquid) and solid particles. Computational Fluid Dynamics (CFD) for
> > the fluid phase, the Discrete
> > Element Method (DEM) for granular material, and their combination
> > (CFD-DEM) enable us to
> > predict the dynamics of these unit operations. This requires
> > high-performance robust models for
> > which the components (linear solver, finite element formulation) are
> > tailored to the application.
> >
> > In this talk, we introduce a new open-source CFD, DEM and CFD-DEM
> > software: Lethe. Lethe is built
> > upon the well-established deal.II library. It leverages deal.II not
> > only for its state of the art FEM
> > capabilities, but it also makes extensive usage of its
> > high-performance particle tracking module for
> > its DEM solver. We present four very different examples that highlight
> > the challenges that the
> > chemical engineering community face and that can be addressed through
> > simulations:
> > - The mixing of shear-thinning fluids.
> > - The prediction of early turbulent flows.
> > - The flow of powder.
> > - The solid-fluid flow in a fluidized bed reactor.
> >
> > For each of these examples, we discuss the mathematical formulation
> > that we use within Lethe as
> > well as the technical challenges faced when developing the models. We
> > conclude by providing a
> > high-level perspective of the direction in which we are heading, the
> > challenges that we are currently
> > facing and the key lessons that have been learned through this
> > endeavor to develop a
> > CFD/DEM/CFD-DEM software.
> >
> > Best,
> > Timo
> >
> > --
> > Timo Heister
> > http://www.math.clemson.edu/~heister/
>
>
>
> -- 
> Timo Heister
> http://www.math.clemson.edu/~heister/
>

-- 
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/6e5bd3be-ccc6-4b0b-ab75-025ea76e5a1cn%40googlegroups.com.

[deal.II] Re: Smooth particles hydrodynamic implementation in DealII

[blais...@gmail.com]

Dear Hassan,
There is no way to do that directly in Deal.II
Lethe adds two classes to achieve this using a coarse and then a fine 
contact detection.
https://github.com/lethe-cfd/lethe/blob/master/include/dem/particle_particle_broad_search.h
https://github.com/lethe-cfd/lethe/blob/master/include/dem/particle_particle_fine_search.h

If you are interested, we could eventually try to port them to deal.II, but 
these are very lethe specific at the moments.
Otherwise, you can use these ideas to generate your contact list. These 
will work if you use the background mesh as your contact detection grid 
(which is what we do, it's quite efficient and robust).


On Saturday, February 12, 2022 at 3:59:16 a.m. UTC-5 hassan...@gmail.com 
wrote:

> Dear Wolfgang and Bruno 
>
> thank you for your answers. I will study the 'lethe' code. 
> I want to apply constraints on linear momentum for a set of particles. 
> Actually, I want to build an SPH code from scratch. We are working with a 
> total Lagrangian formulation, so position of particles is constant. 
> Additionally.  we are working with just a layer of neighbor particles in 
> each direction. I did't understand how to find neighbor particles, I was 
> looking for a way to access neighbor particles, something like the one that 
> is used for the cell in step-68 "particle->get_surrounding_cell()".
>
> Thanks
> Hassan
>
> On Saturday, February 12, 2022 at 6:27:09 AM UTC+3:30 blais...@gmail.com 
> wrote:
>
>> If I may suggest, at that point, I would ask you what you are trying to 
>> specifically achieve?
>> If you want to build an SPH code from scratch, this is definitely 
>> possible to do using deal.II particle classes (esp. with the exchange and 
>> update ghosts functionalities), but this will require a lot of work. In 
>> that case, it might also be a good idea to look at an SPH code designed 
>> from scratch for this (e.g. DualSPHPhysics is a good one)
>> In our case, we built our DEM code using deal.II because
>> A) DEM is simpler than SPH (shorter scale interaction)
>> B) We wanted to couple our DEM to our CFD and deal.II was the perfect 
>> vehicle for that.
>>
>> It is definitely doable to build from scratch, but it will be a massive 
>> endeavour to make it fast.
>>
>>
>>
>> On Thursday, February 10, 2022 at 3:34:13 a.m. UTC-5 hassan...@gmail.com 
>> wrote:
>>
>>> Dear dealII users
>>>
>>> I want to solve a series of conservation law using smooth particles 
>>> hydrodynamics (SPH). I am looking for a parallel solution.  could you 
>>> please help me to setup my code correctly.
>>>
>>> 1- The number of unknowns is 11 (linear momentum 3 components and 
>>> deformation gradient 9 components). In addition to that I have to save 
>>> stress tensor, smoothing length, pressure and some other state variables at 
>>> each particles. So the number of variable that I want to store is huge. 
>>> Should I store them as 'property' at each particle? 
>>>
>>> 2- I want to have a particle at each vertex on the triangulation. How to 
>>> create them?
>>>
>>> 3- How to create and apply constraints?
>>>
>>> 4- Finally, (the most important question), in a solution  using the SPH 
>>> method  computation is done on each particle (Target particle) according to 
>>> data belong to the particles are around the target particle (Neighbor 
>>> particles) . How to access to the data that belong to the neighbor 
>>> particle. For simplicity at this moment we can consider that the neighbor 
>>> particles are just the particles connected to the target particle on the 
>>> adjacent cell (one layer). 
>>>
>>> Beta regards,
>>> Hassan
>>>
>>

-- 
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/0c9e683f-a186-47df-aee8-486611818ebbn%40googlegroups.com.

[deal.II] Re: Smooth particles hydrodynamic implementation in DealII

[blais...@gmail.com]

If I may suggest, at that point, I would ask you what you are trying to 
specifically achieve?
If you want to build an SPH code from scratch, this is definitely possible 
to do using deal.II particle classes (esp. with the exchange and update 
ghosts functionalities), but this will require a lot of work. In that case, 
it might also be a good idea to look at an SPH code designed from scratch 
for this (e.g. DualSPHPhysics is a good one)
In our case, we built our DEM code using deal.II because
A) DEM is simpler than SPH (shorter scale interaction)
B) We wanted to couple our DEM to our CFD and deal.II was the perfect 
vehicle for that.

It is definitely doable to build from scratch, but it will be a massive 
endeavour to make it fast.



On Thursday, February 10, 2022 at 3:34:13 a.m. UTC-5 hassan...@gmail.com 
wrote:

> Dear dealII users
>
> I want to solve a series of conservation law using smooth particles 
> hydrodynamics (SPH). I am looking for a parallel solution.  could you 
> please help me to setup my code correctly.
>
> 1- The number of unknowns is 11 (linear momentum 3 components and 
> deformation gradient 9 components). In addition to that I have to save 
> stress tensor, smoothing length, pressure and some other state variables at 
> each particles. So the number of variable that I want to store is huge. 
> Should I store them as 'property' at each particle? 
>
> 2- I want to have a particle at each vertex on the triangulation. How to 
> create them?
>
> 3- How to create and apply constraints?
>
> 4- Finally, (the most important question), in a solution  using the SPH 
> method  computation is done on each particle (Target particle) according to 
> data belong to the particles are around the target particle (Neighbor 
> particles) . How to access to the data that belong to the neighbor 
> particle. For simplicity at this moment we can consider that the neighbor 
> particles are just the particles connected to the target particle on the 
> adjacent cell (one layer). 
>
> Beta regards,
> Hassan
>

-- 
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/acc6ffbc-b940-4506-9c95-5aecfaeba317n%40googlegroups.com.

[deal.II] Re: Triangular Meshes in deal.II

[blais...@gmail.com]

Dear Pushkar,
Deal.II supports simplex meshes, you can look at the documentation : 
https://www.dealii.org/current/doxygen/deal.II/group__simplex.html
Consequently, you can import a 2D triangular mesh made with GMSH, or you 
can transform a quad mesh generated by deal.II into a simplex mesh.

Best
Bruno


On Wednesday, November 10, 2021 at 6:32:30 a.m. UTC-5 pushkar...@gmail.com 
wrote:

> Dear deal.II community
>
> I am trying to verify a formulation from one of the book in which the 
> corresponding code has a triangular mesh as opposed to square mesh . In  
> this regard,I wish to know whether I can input a triangular mesh into 
> deal.II. Also,I donot wish to use AMR as I just want to verify the 
> formulation using sepicified mesh density.
>
> Thanks in Advance
> Pushkar
>

-- 
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/99629c8b-0008-4a3d-9379-e4ab920e7c8dn%40googlegroups.com.

Re: [deal.II] Are there known issue between Trilinos 13.0.1 and deal.II?

[blais...@gmail.com]

Dear all,

After discussion with my cluster admin, he suggested the use of the 
following flag:

-DTrilinos_FIND_COMPONENTS="Pike;PikeImplicit;PikeBlackBox;TrilinosCouplings;Panzer;PanzerMiniEM;PanzerAdaptersSTK;PanzerDiscFE;PanzerDofMgr;PanzerCore;Piro;ROL;Stokhos;Tempus;Rythmos;ShyLU;ShyLU_DD;ShyLU_DDCommon;ShyLU_DDFROSch;ShyLU_DDBDDC;Zoltan2;Zoltan2Sphynx;MueLu;Moertel;NOX;Phalanx;Percept;STK;STKExprEval;STKDoc_tests;STKUnit_tests;STKBalance;STKTools;STKTransfer;STKSearchUtil;STKSearch;STKUnit_test_utils;STKNGP_TEST;STKIO;STKMesh;STKTopology;STKSimd;STKUtil;STKMath;Compadre;Intrepid2;Intrepid;Teko;FEI;Stratimikos;Ifpack2;Anasazi;Komplex;SEACAS;SEACASEx2ex1v2;SEACASTxtexo;SEACASNumbers;SEACASNemspread;SEACASNemslice;SEACASMat2exo;SEACASMapvar-kd;SEACASMapvar;SEACASMapvarlib;SEACASExplore;SEACASGrepos;SEACASGenshell;SEACASGen3D;SEACASGjoin;SEACASFastq;SEACASEx1ex2v2;SEACASExo_format;SEACASExotxt;SEACASExomatlab;SEACASExodiff;SEACASExo2mat;SEACASEpu;SEACASEjoin;SEACASConjoin;SEACASBlot;SEACASAprepro;SEACASAlgebra;SEACASPLT;SEACASSVDI;SEACASSuplibCpp;SEACASSuplibC;SEACASSuplib;SEACASSupes;SEACASAprepro_lib;SEACASChaco;SEACASIoss;SEACASNemesis;SEACASExoIIv2for32;SEACASExodus_for;SEACASExodus;Amesos2;ShyLU_Node;ShyLU_NodeTacho;ShyLU_NodeHTS;Belos;ML;Ifpack;Zoltan2Core;Pamgen;Amesos;Galeri;AztecOO;Pliris;Isorropia;Xpetra;Thyra;ThyraTpetraAdapters;ThyraEpetraExtAdapters;ThyraEpetraAdapters;ThyraCore;Domi;TrilinosSS;Tpetra;TpetraCore;TpetraTSQR;TpetraClassic;EpetraExt;Triutils;Shards;Zoltan;Epetra;MiniTensor;Sacado;RTOp;KokkosKernels;Teuchos;TeuchosKokkosComm;TeuchosKokkosCompat;TeuchosRemainder;TeuchosNumerics;TeuchosComm;TeuchosParameterList;TeuchosParser;TeuchosCore;Kokkos;KokkosAlgorithms;KokkosContainers;KokkosCore;Gtest;TrilinosATDMConfigTests;TrilinosFrameworkTests"

I guess this enables us to choose which Trilinos components we include and 
which we don't. Interesting to say the least, I will have to test more to 
see if this has consequences.
Thank you for your help and your time. This is always greatly appreciated. 
I hope this may help others in the future.
Best
Bruno

On Friday, October 29, 2021 at 10:01:15 a.m. UTC-4 bruno.t...@gmail.com 
wrote:

> Bruno,
>
> It looks like you are not the only one to have this problem:
> https://github.com/trilinos/Trilinos/issues/8299
> https://github.com/trilinos/Trilinos/issues/9426
>
> Possible solution from the second issue:  use `-DBUILD_SHARED_LIBS:BOOL=OFF` 
> or add -undefined dynamic_lookup to CMAKE_CXX_FLAGS
>
> Best,
>
> Bruno
> On Friday, October 29, 2021 at 9:41:01 AM UTC-4 Wolfgang Bangerth wrote:
>
>> On 10/29/21 7:10 AM, blais...@gmail.com wrote:
>> > Is there a way to disable the usage of Zadelus from deal.II?
>> > I don't see any CMAKE options that I could pass to disable Zadelus.
>> > I tried googling the component and I can't figure out what it is...
>> > :)
>> > I'll ask my cluster administrator to recompile Trilinos with Zadelus, I 
>> just 
>> > hope it's not an old component that was deprecated in Trilinos 13.0.1
>>
>> I think you will have to recompile Trilinos without that specific 
>> package. 
>> When you compile Trilinos, you pass a list of cmake flags of the form 
>> TPL_ENABLE_... for the package you want, and you probably want to omit 
>> (or 
>> explicitly disable) the one that is the problem.
>>
>> 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/b2cffa25-73ac-4b7b-b7ba-bed99b9aa9c3n%40googlegroups.com.

Re: [deal.II] Are there known issue between Trilinos 13.0.1 and deal.II?

[blais...@gmail.com]

Is there a way to disable the usage of Zadelus from deal.II?
I don't see any CMAKE options that I could pass to disable Zadelus.
I tried googling the component and I can't figure out what it is...
:)
I'll ask my cluster administrator to recompile Trilinos with Zadelus, I 
just hope it's not an old component that was deprecated in Trilinos 13.0.1

Thanks for the help! I really appreciate it.

Best
Bruno



On Friday, October 29, 2021 at 8:38:57 a.m. UTC-4 Wolfgang Bangerth wrote:

> On 10/29/21 5:10 AM, blais...@gmail.com wrote:
> > 
> > Is Adelus a Trilinos component that is mandatory? In my case, this is 
> clearly 
> > the issue, if this component is not there, then that's why I am getting 
> this 
> > error.
>
> I have never heard of that component. You can probably disable it.
>
> A good question is why the error happens in the first place. I believe 
> (Matthias might be able to confirm) that we import the list of libraries 
> to 
> link with from Trilinos. Apparently, this list did not, but should have, 
> included the Adelus library. That might be a Trilinos bug, but that is no 
> consolation.
>
> 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/90a2287d-56c1-45bb-888c-ddb1976d2109n%40googlegroups.com.

Re: [deal.II] Are there known issue between Trilinos 13.0.1 and deal.II?

[blais...@gmail.com]

Dear Martin,
I guess I was being overly enthusiastic. I understand now, every "failed 
test" (e.g.  DEAL_II_HAVE_CXX20_FEATURES) end up in this file.
The majority of the "errors" I get are thus regular configuration "failure"

The final failure I get is related to : Performing C++ SOURCE FILE Test 
DEAL_II_HAVE_USABLE_FLAGS_DEBUG failed with the following output:
Change Dir: /home/blaisbru/dealii/build/CMakeFiles/CMakeTmp

It's a massive error message, but the key line appear to be these one to me:
/cvmfs/soft.computecanada.ca/easybuild/software/2020/avx2/MPI/gcc9/openmpi4/trilinos/13.0.1/lib/libzadelus.so:
 
error: undefined reference to 'Adelus::nprocs_col'
/cvmfs/soft.computecanada.ca/easybuild/software/2020/avx2/MPI/gcc9/openmpi4/trilinos/13.0.1/lib/libzadelus.so:
 
error: undefined reference to 'Adelus::me'
/cvmfs/soft.computecanada.ca/easybuild/software/2020/avx2/MPI/gcc9/openmpi4/trilinos/13.0.1/lib/libzadelus.so:
 
error: undefined reference to 'Adelus::nprocs_row'
collect2: error: ld returned 1 exit status
gmake[1]: *** [CMakeFiles/cmTC_c4ee5.dir/build.make:266: cmTC_c4ee5] Error 1
gmake[1]: Leaving directory 
'/home/blaisbru/dealii/build/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:121: cmTC_c4ee5/fast] Error 2

Source file was:
int main(){ return 0; }

Is Adelus a Trilinos component that is mandatory? In my case, this is 
clearly the issue, if this component is not there, then that's why I am 
getting this error.

Thank you very much for the help! This community is always so amazing.




On Friday, October 29, 2021 at 6:54:11 a.m. UTC-4 Martin Kronbichler wrote:

> Dear Bruno,
>
> This is a regular error and not related to the actual problem I believe. 
> This is simply the message that we use to detect what SIMD extensions we 
> can enable, and in your case the compilation does not support AVX. But I 
> think further down in the CMakeFiles/CMakeError.log file you should find 
> the culprit.
>
> As a side remark, the AMD Rome architecture does indeed support AVX2, as 
> long as you pass "-mavx2 -mfma" or "-march=znver2" or simply 
> "-march=native" to the compile flags ("CMAKE_CXX_FLAGS"). However, AMD does 
> not (yet) support AVX-512, which might be what you're referring to. In 
> other words, the compiler needs to be told what kind of architecture 
> extensions are supported on the target CPU. I most often use 
> "-march=native" unless I'm cross-compiling on a different CPU compared to 
> where the code is eventually executed.
>
> Best,
> Martin
> On 29.10.21 12:47, blais...@gmail.com wrote:
>
> Wolfgang, you are a genius.
> The exact error I am getting is related to AVX instructions not being 
> available. I think this is normal because this is an AMD Rome based cluster 
> and not an intel one.
>
> Run Build Command(s):/cvmfs/
> soft.computecanada.ca/gentoo/2020/usr/bin/gmake cmTC_be568/fast && /cvmfs/
> soft.computecanada.ca/gentoo/2020/usr/bin/gmake -f 
> CMakeFiles/cmTC_be568.dir/build.make CMakeFiles/cmTC_be568.dir/build
> gmake[1]: Entering directory 
> '/home/blaisbru/dealii/build/CMakeFiles/CMakeTmp'
> Building CXX object CMakeFiles/cmTC_be568.dir/src.cxx.o
> /cvmfs/
> soft.computecanada.ca/easybuild/software/2020/Core/gcccore/9.3.0/bin/c++
> -DDEAL_II_HAVE_AVX   -o CMakeFiles/cmTC_be568.dir/src.cxx.o -c 
> /home/blaisbru/dealii/build/CMakeFiles/CMakeTmp/src.cxx
> /home/blaisbru/dealii/build/CMakeFiles/CMakeTmp/src.cxx:3:6: error: #error 
> "__AVX__ flag not set, no support for AVX"
> 3 | #error "__AVX__ flag not set, no support for AVX"
>   |  ^
> /home/blaisbru/dealii/build/CMakeFiles/CMakeTmp/src.cxx: In function ‘int 
> main()’:
> /home/blaisbru/dealii/build/CMakeFiles/CMakeTmp/src.cxx:35:9: warning: AVX 
> vector return without AVX enabled changes the ABI [-Wpsabi]
>35 |   b = _mm256_set1_pd (static_cast(2.25));
>   |   ~~^
> gmake[1]: *** [CMakeFiles/cmTC_be568.dir/build.make:66: 
> CMakeFiles/cmTC_be568.dir/src.cxx.o] Error 1
> gmake[1]: Leaving directory 
> '/home/blaisbru/dealii/build/CMakeFiles/CMakeTmp'
> gmake: *** [Makefile:121: cmTC_be568/fast] Error 2
>
> Hopefully I find a solution from there :)!
>
>
> On Thursday, October 28, 2021 at 11:20:42 p.m. UTC-4 Wolfgang Bangerth 
> wrote:
>
>> On 10/28/21 8:02 PM, blais...@gmail.com wrote: 
>> > 
>> > However, whenever I run CMAKE using deal.II AND enabling Trilinos, I 
>> get the 
>> > following error: 
>> > Configuration error: Cannot compile a test program with the final set 
>> of 
>> > compiler and linker flags: 
>> > CXX flags (DEBUG): -pedantic -fPIC -Wall -We

Re: [deal.II] Are there known issue between Trilinos 13.0.1 and deal.II?

[blais...@gmail.com]

Wolfgang, you are a genius.
The exact error I am getting is related to AVX instructions not being 
available. I think this is normal because this is an AMD Rome based cluster 
and not an intel one.

Run Build Command(s):/cvmfs/soft.computecanada.ca/gentoo/2020/usr/bin/gmake 
cmTC_be568/fast && /cvmfs/soft.computecanada.ca/gentoo/2020/usr/bin/gmake 
-f CMakeFiles/cmTC_be568.dir/build.make CMakeFiles/cmTC_be568.dir/build
gmake[1]: Entering directory 
'/home/blaisbru/dealii/build/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_be568.dir/src.cxx.o
/cvmfs/soft.computecanada.ca/easybuild/software/2020/Core/gcccore/9.3.0/bin/c++ 
   
-DDEAL_II_HAVE_AVX   -o CMakeFiles/cmTC_be568.dir/src.cxx.o -c 
/home/blaisbru/dealii/build/CMakeFiles/CMakeTmp/src.cxx
/home/blaisbru/dealii/build/CMakeFiles/CMakeTmp/src.cxx:3:6: error: #error 
"__AVX__ flag not set, no support for AVX"
3 | #error "__AVX__ flag not set, no support for AVX"
  |  ^
/home/blaisbru/dealii/build/CMakeFiles/CMakeTmp/src.cxx: In function ‘int 
main()’:
/home/blaisbru/dealii/build/CMakeFiles/CMakeTmp/src.cxx:35:9: warning: AVX 
vector return without AVX enabled changes the ABI [-Wpsabi]
   35 |   b = _mm256_set1_pd (static_cast(2.25));
  |   ~~^
gmake[1]: *** [CMakeFiles/cmTC_be568.dir/build.make:66: 
CMakeFiles/cmTC_be568.dir/src.cxx.o] Error 1
gmake[1]: Leaving directory 
'/home/blaisbru/dealii/build/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:121: cmTC_be568/fast] Error 2

Hopefully I find a solution from there :)!


On Thursday, October 28, 2021 at 11:20:42 p.m. UTC-4 Wolfgang Bangerth 
wrote:

> On 10/28/21 8:02 PM, blais...@gmail.com wrote:
> > 
> > However, whenever I run CMAKE using deal.II AND enabling Trilinos, I get 
> the 
> > following error:
> > Configuration error: Cannot compile a test program with the final set of
> > compiler and linker flags:
> > CXX flags (DEBUG): -pedantic -fPIC -Wall -Wextra -Wmissing-braces 
> > -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wsuggest-override 
> > -Wswitch -Wsynth -Wwrite-strings -Wno-placement-new 
> > -Wno-deprecated-declarations -Wno-literal-suffix -Wno-psabi 
> > -Wno-class-memaccess -fopenmp-simd -Wno-parentheses 
> -Wno-unused-local-typedefs 
> > -O0 -ggdb -Wa,--compress-debug-sections
>
> Somewhere, in some file that is probably located under CMakeFiles in your 
> build directory, it will provide you with whatever error messages cmake 
> got 
> when it tried to compile a test program with these flags. If you know what 
> that error is, you're probably 75% there towards identifying what the real 
> underlying problem is.
>
> 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/fb910de8-53f0-4eca-90a7-14a54e3069a1n%40googlegroups.com.

[deal.II] Are there known issue between Trilinos 13.0.1 and deal.II?

[blais...@gmail.com]

Dear All,
I hope you are well.
I am trying to compile deal.II on a new cluster in Canada called Narval 
(named after another cute whale, we love those up north). It uses the 
following versions of the core library that we need:
gcc/9.3.0
openmpi/4.0.3
trilinos/13.0.1
parmetis/4.0.3
p4est/2.2

However, whenever I run CMAKE using deal.II AND enabling Trilinos, I get 
the following error:
Configuration error: Cannot compile a test program with the final set of
compiler and linker flags:
  CXX flags (DEBUG): -pedantic -fPIC -Wall -Wextra -Wmissing-braces 
-Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wsuggest-override 
-Wswitch -Wsynth -Wwrite-strings -Wno-placement-new 
-Wno-deprecated-declarations -Wno-literal-suffix -Wno-psabi 
-Wno-class-memaccess -fopenmp-simd -Wno-parentheses 
-Wno-unused-local-typedefs -O0 -ggdb -Wa,--compress-debug-sections

I'll spare you the rest of the Blabla.
This is clearly something I need to fix with my cluster admin. However, 
before i delve into this, have any of you faced such issue? Is it an issue 
with Trilinos 130.1, or is this  a cluster-related issue?

Thank  you so much
Bruno



-- 
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/87dc8659-1d0c-420d-99c2-4d98764f78f8n%40googlegroups.com.

[deal.II] Re: Coarsening grid from Abaqus imported mesh

[blais...@gmail.com]

Dear Truong,
My understanding is that the triangulation in deal.II works like a 
quad/oct-forest.That is, the mesh that is generated or read serves as the 
forest and each cell is a tree. Consequently, it is not possible to coarsen 
a mesh more than it's initial configuration.

For a lot of meshes generated by deal.II, this is not a problem since they 
contain a very low number of cells (for example, a cubic grid has 1 cell in 
it's coarsest level, hence it is a forest with once tree). However, if you 
read your mesh from an external source, you cannot make it coarser than it 
is when you have read it.

My suggestions would be to make a coarse abacus mesh, then you refine it 
within deal.II. This way you would have a coarsest level with as few cell a 
possible, then you could refine it adaptively. As far as I know, it is not 
possible to coarsen a mesh below it's level 0, because this would imply 
"merging cell".

I hope that was sufficiently clear.
Best of luck!
Bruno

On Tuesday, August 31, 2021 at 9:26:32 a.m. UTC-4 truongthangp...@gmail.com 
wrote:

> Hello everyone,
> I am new to deal.II and I am playing around with the grid of L-shape which 
> is imported from Abaqus input file using GridIn::read_abaqus(). The grid 
> has been successfully read as well as the boundary indicators ( from the 
> surface with the name of "SS1" and "SS2"). However, when I try to do 
> coarsening the grid by setting cell->set_coarsen_flag(), nothing happened. 
> I also tested with adaptive refinement as in step-6, only a figure of the 
> new cell has been generated, none has been coarsened even I set the 
> coarsening ratio to high value. 
> I wonder what is wrong here or is there something that I misunderstand 
> with the code. Thanks in advance. 
>
> [image: Capture.PNG]
> [image: Capture.PNG]
>

-- 
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/e71f5ab4-b69e-49d0-8580-00d567938163n%40googlegroups.com.

Re: [deal.II] Re: Subdivided cylinder and boundary ids

[blais...@gmail.com]

This issue is now fixed by a PR merged yesterday.
Best
Bruno


On Monday, June 28, 2021 at 6:40:04 a.m. UTC-4 alexanderc...@gmail.com 
wrote:

> Hi Bruno,
>
> Sure, I can try making a PR this week.
>
> Best,
> Alex
>
> On Sunday, June 27, 2021 at 9:36:50 p.m. UTC+2 blais...@gmail.com wrote:
>
>> I most likely copied this mistake from the regular Cylinder and did not 
>> think of it when I coded the subdivided cylinder.
>> Alex, if you feel comfortable, you could go ahead and make a PR following 
>> Wolfgang's suggestion. Otherwise, I'll gladly look into it this week :)
>> Best
>> BRuno
>>
>>
>> On Friday, June 25, 2021 at 11:52:51 p.m. UTC-4 Wolfgang Bangerth wrote:
>>
>>> On 6/25/21 12:37 PM, Marc Fehling wrote: 
>>> > # Instead of an absolute threshold, you can introduce a relative one, 
>>> for 
>>> > example, `epsilon * cell->diameter()` or something similar. 
>>>
>>> FWIW, in most places, this is what we 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/64f0d14c-bacf-4b33-84d9-6c36253b26e6n%40googlegroups.com.

Re: [deal.II] Re: Grid deformation after load-balancing

[blais...@gmail.com]

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/142ad76a-a4ec-4fd1-b435-a402d82056a4n%40googlegroups.com.

[deal.II] Re: Grid deformation after load-balancing

[blais...@gmail.com]

Peter this is what I suspected :).
Is that not a bit of an ill-defined behavior for the triangulations? 
Shouldnt the manifolds also translate themselves when the triangulation is 
translated? 
Clearly, it is possible to reset the manifold every time the triangulation 
is moved, but this becomes a very manual process. I feel like it would be 
some sort of a hack.




On Wednesday, August 4, 2021 at 3:43:15 a.m. UTC-4 peterrum wrote:

> Hi Shahab,
>
> My best guess is that the attached manifold is not consistent to what you 
> need after the grid transformations. You have to be aware that the attached 
> manifold is used for generating new vertices (as it is needed during 
> AMR/load-balancing in regions that is newly owned by a rank). Maybe you 
> could attach a new `CylindricalManifold` via  `tria.set_manifold(0, 
> CylindricalManifold<3>(/*TODO: appropriate arguments*/));` (with arguments 
> consistent to the transformation). Hopefully, this fixes your problem!
>
> PM
>
> On Monday, 2 August 2021 at 21:33:59 UTC+2 bruno.t...@gmail.com wrote:
>
>> Shahab.
>>
>> You can loop over the cells, get the vertices (see 
>> https://dealii.org/current/doxygen/deal.II/classTriaAccessor.html#a3dd6518eb0cf5fccc5926470128415d9)
>>  
>> and print the Point associated to each vertex. Then you can compare the 
>> vertices before and after load balancing.
>>
>> Best,
>>
>> Bruno
>>
>> On Monday, August 2, 2021 at 1:12:09 PM UTC-4 shahab.g...@gmail.com 
>> wrote:
>>
>>> 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/47224910-2b0b-419a-bb2d-7fefdd4fd6b4n%40googlegroups.com.

[deal.II] Re: profiling and parallel performance of deal.II user codes

[blais...@gmail.com]

Dear Richard,
I have used valgrind's callgrind tool extensively in the past and it works 
quite well.
It seems Intel VTune is free now. I have used it a lot in the last two 
months to optimize our code and I have found it work very, very well. We 
managed to improve some functions tremendously because of it.
It is also significantly faster than callgrind, enabling you to profile on 
larger cases.
Best
Bruno


On Tuesday, August 3, 2021 at 9:58:07 a.m. UTC-4 richard@gmail.com 
wrote:

> Dear all,
> I spent quite some time on our in-house CFD and FSI solvers, which are 
> matrix-based and use deal.II, MPI and AMG packages of Trilinos and PETSc, 
> all of which are so wonderfully accessible even for engineers like me. My 
> computations now focused on problems with relatively small DoF count - say, 
> max. 10 mio. - and the number of mpi ranks  was eye-balled, staying below 
> 20. At this stage, I would like to know 
>
> a) which (free) profiling tools can you recommend? I watched the video 
> lecture of Wolfgang about that topic, but was looking for more opinions! I 
> want to see which parts of the code take time apart from the (already 
> detailed) TimerOutput.
>
> b) If I use simply "mpirun -n 4 mycode" on a machine with 8 physical 
> cores, why do both PETSc and Trilinos use 8 cores during the AMG setup and 
> solve? I observed that using the htop command, even when using an 
> off-the-shelf "step-40.release" as included in the library. Does anyone 
> else see that? It looks something like this during the AMG setup and solve 
> for "mpirun -n 8 step-40":
> [image: screenshot_trilinos_step40_mpirun_n_8.png]
> It might be linked to the installation on the server, where I used candi. 
> On my local machine, however, this does not happen. 
>
> Any hints are very much welcome, thanks for reading and any tips!
>
> Best regards & greetings from Graz
> Richard
>
>

-- 
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/5705d2b5-5fa7-44c6-a857-17c634e4ef1en%40googlegroups.com.

Re: [deal.II] Deal.II programming environment

[blais...@gmail.com]

Hi Martin,
Multiple IDEs work very well with Deal.II. As long as your IDE has good 
CMAKE support, compiling deal.II with it is a joke.
Some IDEs which me and my colleagues have found work very well in the 
present case:
- Jetbrains CLION (this one is not free, but for a reason I don't 
understand it's by far the one my students prefer to use. It is super nice 
though with very good Cmake integration)
- QTCreator (which is free and has amazing cmake integration. It is not 
difficult to set-up)

And then you could use a text editor with IDE-like capacities like VSCode 
which, especially with the newer version of cmake extensions, works 
amazingly well. As long as your deal.II environment variable is set-up 
correctly, I have found that you can naviguate through your own code and 
the deal.II library in mere seconds. It is truly easy to use once set-up.

I feel that's the challenge with these tools. Once set-up, they are amazing 
and they improve your workflow a lot (e.g. using VSCode on your machine to 
code something in a WSL or a virtual machine is an amazingly productive way 
of working under Windows), but they are difficult to set-up :)

Good luck!
Bruno B 


On Thursday, July 22, 2021 at 1:23:22 a.m. UTC-4 jian...@gmail.com wrote:

> Hi  Jean-Paul,
>
> Thanks for the suggestion, I will give it a go and find out.
>
> In order to use  deal.II, I find we have to become an part-time computer 
> scientist, the means defeats the goal, haha
>
> Best regards
> Martin
>
>
> On Thursday, 22 July 2021 at 2:53:29 pm UTC+10 Jean-Paul Pelteret wrote:
>
>> Hi Martin,
>>
>> This is the sort of case where where VSCode is really useful. It has an 
>> easy to use remote development extension, where you would open and use the 
>> editor in Windows but you’d be editing and building files on the virtual 
>> machine. Here are a couple of official links that explain the concept, and 
>> if this interests you then I think that a quick google search would be able 
>> to clear up the details on how to set it all up. 
>> https://code.visualstudio.com/docs/remote/ssh
>> https://code.visualstudio.com/docs/remote/ssh-tutorial
>>
>> The hardest thing is getting the initial ssh connection to the virtual 
>> machine working, because after that you can navigate the virtual machine in 
>> VSCode and set up a workspace as if it was the physical machine that you’re 
>> working on.
>>
>> Best,
>> Jean-Paul
>>
>>
>> On 22. Jul 2021, at 04:02, Jiang Hu  wrote:
>>
>> Hi Bruno,
>>
>> Thanks for the link. 
>> The thing is, I am using a virtual box machine with Deal.II and Ubuntu. 
>> where should I get Eclipse installed? I guess doing it in windows should 
>> not work.
>>
>> Thanks for your time.
>> Martin 
>>
>>
>> On Wednesday, 21 July 2021 at 10:11:01 pm UTC+10 bruno.t...@gmail.com 
>> wrote:
>>
>>> Martin,
>>>
>>> You can use whatever you like, there is no such thing as a typical 
>>> environment. With that being said, we do have documentation and videos to 
>>> help you setup Eclipse. See 
>>> https://github.com/dealii/dealii/wiki/Eclipse
>>> https://www.math.colostate.edu/~bangerth/videos.676.7.html
>>> https://www.math.colostate.edu/~bangerth/videos.676.8.html
>>> https://www.math.colostate.edu/~bangerth/videos.676.8.01.html
>>>
>>> Best,
>>>
>>> Bruno
>>>
>>> On Wednesday, July 21, 2021 at 1:22:36 AM UTC-4 jian...@gmail.com wrote:
>>>
 Hello everyone,

 Quite excited to find Deal.II and its potential.

 I installed virtual machine with Deal.II, and run step 7 on terminal 
 without any problem.

 The question is if I want to compile bigger program with Deal.II , what 
 is the typical working environment? 

 I assume we can not with terminal for such a purpose. I saw people 
 using Nano to run Deal.II, but want to ask the standard tool for such 
 process.

 Emacs or Vscode?  Do I need to connect them to Deal.II?

 I am very new, and this could be a quite silly question.

 Thanks 

 Martin

>>>
>> -- 
>> 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+un...@googlegroups.com.
>>
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/dealii/d44db170-42e1-463d-8e39-3f0b096c215en%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 

[deal.II] Re: Step-77 not working using Sundials 5.7.0

[blais...@gmail.com]

In addition,
Step-77 does not compile with the Sundials 3.1.0 distributed with candi.
The following error is obtained at run time in debug mode:

An error occurred in line <427> of file 
 in function
unsigned int dealii::SUNDIALS::KINSOL::solve(VectorType&) 
[with VectorType = dealii::Vector]
The violated condition was: 
solve_jacobian_system
Additional information: 
Please provide an implementation for the function
"solve_jacobian_system"

Stacktrace:
---
#0  /home/blaisb/work/dealii/inst/lib/libdeal_II.g.so.10.0.0-pre: 
dealii::SUNDIALS::KINSOL 
>::solve(dealii::Vector&)
#1  ./step-77.debug: Step77::MinimalSurfaceProblem<2>::run()
#2  ./step-77.debug: main


In release you just get a segfault.
This could be fixed by adding the solve_jacobian_system. However, even with 
this, the example does not converge. I'd rather wait on the feedback on 
this before moving ahead and opening a PR for 3.1.0 compatibility.
:)


On Monday, July 12, 2021 at 12:25:10 p.m. UTC-4 Laura Prieto wrote:

> Follow up: just tested with Sundials 3.1 and I get the same error with 
> similar values for the norms
>
> El lunes, 12 de julio de 2021 a las 12:18:52 UTC-4, Laura Prieto escribió:
>
>> Dear deal.ii community, 
>>
>> I am testing step-77 using the latest deal.ii release with sundials on 
>> (version 5.7.0). The example compiles and runs but not as expected, as I 
>> get the following output:
>>
>> Mesh refinement step 0
>>   Target_tolerance: 0.001
>>
>>   Computing residual vector... norm=0.231202
>>   Computing Jacobian matrix
>>   Factorizing Jacobian matrix
>>   Solving linear system
>>   Computing residual vector... norm=0.231202
>>   Computing residual vector... norm=0.402211
>>   Computing residual vector... norm=0.627191
>>   Computing residual vector... norm=0.857696
>>   Computing residual vector... norm=1.08878
>>   Computing residual vector... norm=1.31995
>>   Computing residual vector... norm=1.55112
>>   Computing residual vector... norm=1.78231
>>   Computing residual vector... norm=2.0135
>>   Computing residual vector... norm=2.24469
>>   Computing residual vector... norm=2.47588
>>   Computing residual vector... norm=2.70708
>>
>> [KINSOL ERROR]  KINSol
>>   The line search algorithm was unable to find an iterate sufficiently 
>> distinct from the current iterate.
>>
>> 
>> An error occurred in line <518> of file 
>>  in function
>> unsigned int dealii::SUNDIALS::KINSOL::solve(VectorType&) 
>> [with VectorType = dealii::Vector]
>> The violated condition was: 
>> status >= 0
>> Additional information: 
>> One of the SUNDIALS KINSOL internal functions returned a negative
>> error code: -5. Please consult SUNDIALS manual.
>>
>> I wonder if this has something to do with my Sundials version or if 
>> anybody has a hint of what is happenning?
>>
>> Thank you in advance,
>>
>> Laura
>>
>>

-- 
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/ca324972-5af0-405c-bba9-01e4412d6b76n%40googlegroups.com.

Re: [deal.II] Re: Subdivided cylinder and boundary ids

[blais...@gmail.com]

I most likely copied this mistake from the regular Cylinder and did not 
think of it when I coded the subdivided cylinder.
Alex, if you feel comfortable, you could go ahead and make a PR following 
Wolfgang's suggestion. Otherwise, I'll gladly look into it this week :)
Best
BRuno


On Friday, June 25, 2021 at 11:52:51 p.m. UTC-4 Wolfgang Bangerth wrote:

> On 6/25/21 12:37 PM, Marc Fehling wrote:
> > # Instead of an absolute threshold, you can introduce a relative one, 
> for 
> > example, `epsilon * cell->diameter()` or something similar.
>
> FWIW, in most places, this is what we 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/2f396547-7ea3-4142-a339-06371ac07782n%40googlegroups.com.

Re: [deal.II] Robust way of setting an affine constraint on a single point

[blais...@gmail.com]

Thank you Wolfgang, this is exactly what I needed :)
Best
Bruno

On Tuesday, June 22, 2021 at 6:04:42 p.m. UTC-4 Wolfgang Bangerth wrote:

> On 6/22/21 3:12 PM, blais...@gmail.com wrote:
> > 
> > This is most likely a very simple question, but what would be a good way 
> to 
> > robustly set an AffineConstraint not on a face, but on a single DOF, 
> while 
> > making sure that it is not an hanging node. I'd like to do something 
> > equivalent to what is done by VectorTools::interpolate_boundary_values 
> but for 
> > an a priori unknown DOF (it could be for example the first non-hanging 
> node 
> > DOF or something similar).
>
> As so often, there is precedent for this kind of thing in ASPECT :-)
>
>
> https://github.com/geodynamics/aspect/blob/master/source/simulator/nullspace.cc#L112-L209
>
>
> 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/e4bc4426-5bb0-44da-bfc0-0d46f18ac9ean%40googlegroups.com.

[deal.II] Robust way of setting an affine constraint on a single point

[blais...@gmail.com]

Dear all,
I hope you are well.

This is most likely a very simple question, but what would be a good way to 
robustly set an AffineConstraint not on a face, but on a single DOF, while 
making sure that it is not an hanging node. I'd like to do something 
equivalent to what is done by VectorTools::interpolate_boundary_values but 
for an a priori unknown DOF (it could be for example the first non-hanging 
node DOF or something similar).

This is to set the reference value for a Laplace problem with Neumann Bcs. 
I know there are alternative ways which are better (such as constraining 
the zero mean), but this is for a quick test.

Thank you very much :)!
Bruno


-- 
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/7d5bdc59-2561-4be4-b872-06de50eac7a6n%40googlegroups.com.

Re: [deal.II] Implementing Radiative Losses in Thermal Model

[blais...@gmail.com]

In addition to what Wolfgang said.
If you want to add radiation boundary condition, the first step would be to 
implement a general robin condition. You can see radiation BC following 
Stefan law as a non-linear Robin BCs. Once you have a non-linear heat 
equation solver ready that works with Robin BCs, you can just make your 
Robin boundary condition non-linear and the rest will follow. Luckly, the 
Jacobian matrix arising from the radiation BC is simple because it a  
polynomial BC.

Good luck  and don't hesitate to ask more questions :)
Best
Bruno
On Thursday, June 3, 2021 at 10:31:18 a.m. UTC-4 Wolfgang Bangerth wrote:

> On 6/3/21 7:10 AM, pushkar...@gmail.com wrote:
> > 
> > I would like to seek help regarding the implementation of radiative 
> losses in 
> > thermal model as a BC which will make the system non linear. So it would 
> be 
> > much helpful if someone could direct to relevant tutorial program 
> implementing 
> > the above BC.
>
> Pushkar,
> these sorts of nonlinear boundary conditions are generally included into 
> the 
> weak formulation of the problem via Neumann boundary conditions. Your weak 
> formulation then becomes nonlinear, and if you take a look at step-15, you 
> will see how this kind of problem should be solved.
>
> (You could also look at the new step-72 and step-77 programs to see how 
> certain aspects of this could be simplified.)
>
> Best
> Wolfgang
>
>
> -- 
> 
> 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/67c404e7-cb66-40ae-9152-510b4a743d38n%40googlegroups.com.

Re: [deal.II] Re: dealii::SolverControl::NoConvergence with Bicgstab

[blais...@gmail.com]

I would second what the other Bruno said. I think the easiest 
preconditioner to try would be an ILU preconditioner. You can play with the 
fill level (start from 1 and move up from there). Make sure you set your 
absolute and relative tolerance to a reasonable level though.


On Thursday, April 15, 2021 at 2:23:13 p.m. UTC-4 bruno.t...@gmail.com 
wrote:

> Le jeu. 15 avr. 2021 à 11:57, bunel...@gmail.com  a 
> écrit :
>
>> Hi,
>>
>> thank you very much for your answer. 
>> I have actually tried to solve using GMRES like this :
>>
>> SolverControl  
>> solver_control(phi_system_rhs.size()*2,1e-10);
>> PreconditionJacobi<>   preconditioner;
>> preconditioner.initialize(phi_system_matrix, 1.0);
>> SolverGMRES> solver(solver_control );
>> solver.solve(phi_system_matrix, phi_update, phi_system_rhs, 
>> preconditioner); 
>>
>> and with this, I still get an error because the solver reached the max 
>> number of iteration and did not converge... :
>>
>> "Iterative method reported convergence failure in step 164354. The 
>> residual in the last step was 0.348567."
>>
>  
> Let me rephrase what I said. Non-restarted GMRES is guaranteed to 
> converge. deal.II uses restarted gmres. You can increase the number of 
> iterations before a restart (see 
> https://dealii.org/developer/doxygen/deal.II/structSolverGMRES_1_1AdditionalData.html#ac385db0e8c853c02d828469d5a5bdcca
> )
>
>>
>> Unfortunately, I did not find any literature on preconditioner for my 
>> specific system so I guess I am down to trying them all and seeing if one 
>> of them works...
>>
>
> If you have no idea which preconditioner to use, you can try a black-box 
> preconditioner, such as incomplete LU (ILU), algebraic multigrid (AMG), and 
> geometric multigrid (GMG). ILU and AMG require Trilinos or PETSc. For GMG, 
> there are a couple of tutorials you can look at.
>
> Best,
>
> Bruno
>  
>
>>
>> Le jeudi 15 avril 2021 à 17:41:10 UTC+2, bruno.t...@gmail.com a écrit :
>>
>>> Hi,
>>>
>>> Bicgstab is not guaranteed to converge especially when using a bad 
>>> preconditioner. You are using Jacobi as preconditioner which is a simple 
>>> but not very good preconditioner. As you can see from the error message, 
>>> you performed 1959 bicgstab iterations. That's a lot and it probably 
>>> indicates that there was a breakdown. The easy fix to your problem is to 
>>> use gmres instead of bicgstab. Gmres is guaranteed to converge. The real 
>>> fix is to use a better preconditioner. With a bad preconditioner, gmres 
>>> will converge slowly. You should look in the literature what kind of 
>>> preconditioner you should use.
>>>
>>> Best,
>>>
>>> Bruno
>>>
>>> On Thursday, April 15, 2021 at 4:21:21 AM UTC-4 bunel...@gmail.com 
>>> wrote:
>>>

 Hi, 
 I'm having a problem for some values of parameters in my code.
 I get an error "dealii::SolverControl::NoConvergence", almost instantly 
 after the start of the solving process. The status at the end is this :

 "Iterative method reported convergence failure in step 1959. The 
 residual in the last step was nan."

 Here is some details about my problem. 

 I'm solving this equation in phi :
 [image: Screenshot from 2021-04-15 10-03-35.png]
 with u and v, speeds that are calculated in another part of the code.

 Since it is a non linear problem in phi, i'm using a Newton method to 
 solve it.
 I have developped my Newton Method and calculated the part that I'm 
 assembling.
 [image: Screenshot from 2021-04-15 10-05-29.png]
 As you can see, it is a non symmetric problem because of the advection 
 term and as such, i'm using the Bicgstab solver like this :

 SolverControl  
 solver_control(phi_system_rhs.size()*2,1e-10);
 SolverBicgstab> solver(solver_control);
 PreconditionJacobi<>   preconditioner;

 preconditioner.initialize(phi_system_matrix, 1.0);
 solver.solve(phi_system_matrix, phi_update, phi_system_rhs, 
 preconditioner); 
 phi_constraints.distribute(phi_update);

 Note that if I use a direct solver like this : 

 SparseDirectUMFPACK A_direct;
 A_direct.initialize(phi_system_matrix);
 A_direct.vmult(phi_update, phi_system_rhs); 

 phi_constraints.distribute(phi_update);

 I don't get an error but it is of course much slower (and the newton 
 method painfully converge but I knew this was gonna be difficult).


 "The other situation where this error may occur is when your matrix is 
 not invertible (e.g., your matrix has a null-space), or if you try to 
 apply 
 the wrong solver to a matrix (e.g., using CG for a matrix that is not 
 symmetric or not positive definite). In these cases, the residual in the 
 last iteration is likely going to be large."

[deal.II] Re: deal.II-based FSI matrix-free solver / looking for a post-doc

[blais...@gmail.com]

Dear Michal,
We have a post-doc position available in my group regarding deal.II and 
topology optimisation for conformal cooling.
Please send an email to bruno.bl...@polymtl.ca if you are interested :)!
Best
Bruno


On Saturday, April 17, 2021 at 6:44:44 p.m. UTC-4 mtwich...@gmail.com wrote:

> Dear all,
>  I have developed a parallel matrix-free monolithic FSI solver in the ALE 
> frame of reference. Exemplary results [1 , 2 
> ], more details in my PhD thesis [3] 
> 
> .
>
> *Highlights*:
>
> -> The proposed monolithic predictor-corrector time integration scheme 
> requires solving the generalized Stokes problem with discontinuous variable 
> coefficients. This has to be done one or two times per time step, depending 
> on the variant of the scheme.
>
> -> I have introduced a new multilevel preconditioner, for a 3D case the 
> time required to solve a system consisting of 421 million unknowns using 96 
> cores is 178 seconds.
>
> -> As demonstrated by the movie[1], I am able to solve 3D problems at 
> moderate Reynolds numbers (time step size of 0.01 did not result in any 
> stability issues with Re=2k). 
>
> ->The preconditioner from the thesis can still be greatly improved. I have 
> a proof of concept demonstrating the basic properties of a new idea of 
> smoother. The results look very promising and I'm curious how it would 
> work. Moreover, the algorithm is suitable for GPU that could result in 
> further speedup.
>  
> [1] 3D "Turek benchmark" at Re = 2000 (30M DoF)
> https://youtu.be/7TaC1dTfAQY
> [2] Water hammer in elastic tube (12M DoF)
> https://youtu.be/TRnlt_eC32Q
>
> Those results were obtained as a part of my PhD thesis. I have finally 
> managed to submit it in January, the defence will be held in 3 weeks 
> (expect reviews next week).
> I am looking for a post-doc (preferably deal.II-related). I'll be happy to 
> get an opportunity to continue my work.
>
> Best,
> Michał Wichrowski
>

-- 
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/e9878b7b-4191-4f1c-9a84-b4cbbb307a6an%40googlegroups.com.

Re: [deal.II] Using FEInterfaceValues with FESystems?

[blais...@gmail.com]

Timo,
Don't worry about that. I can't complain if someone else does the work no? 
:) 


On Sunday, March 14, 2021 at 1:07:49 p.m. UTC-4 Timo Heister wrote:

> Bruno, I already have a working implementation of the extractors on my
> machine. I just didn't get the time to clean up, write tests, and
> submit the PR. Sorry. I will try to pick this up again in the next few
> days.
>
> On Fri, Mar 12, 2021 at 12:26 PM Wolfgang Bangerth
>  wrote:
> >
> > On 3/11/21 11:10 PM, blais...@gmail.com wrote:
> > > Let me read the documentation a bit and I could try to come up with a 
> PR.
> > > Maybe this is something we could discuss? I'd be glad to help in 
> improving DG
> > > methods :)
> >
> > Happy to discuss in whatever venue you propose!
> >
> > Start by looking at the FEValuesViews::Scalar class. We'd need a 
> corresponding
> > FEInterfaceValuesViews::Scalar class. Once you know how the former 
> operates,
> > you will probably be able to see how the latter needs to be implemented. 
> I
> > foresee a lot of copy-paste of small functions where the only change is 
> in the
> > 2-3 line bodies.
> >
> > Best
> > Wolfgang
> >
> > --
> > 
> > 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+un...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/5882752f-4530-16b6-41d4-b8b6c9d746f9%40colostate.edu
> .
>
>
>
> -- 
> Timo Heister
> http://www.math.clemson.edu/~heister/
>

-- 
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/633d1b6b-868d-4292-9b3a-0ef5269ba4d1n%40googlegroups.com.

Re: [deal.II] Using FEInterfaceValues with FESystems?

[blais...@gmail.com]

Good to know.
Let me read the documentation a bit and I  could try to come up with a PR. 
Maybe this is something we could discuss? I'd be glad to help in improving 
DG methods :)


On Thursday, March 11, 2021 at 4:29:04 p.m. UTC-5 Wolfgang Bangerth wrote:

> On 3/11/21 10:14 PM, blais...@gmail.com wrote:
> > I am currently trying to solve an advection-diffusion equation at very, 
> very 
> > high Péclet number. I first implemented a GLS-stabilized continuous 
> Galerkin 
> > solution, it works well, but clearly I think a DG approach would be 
> immensely 
> > better here.
> > 
> > The issue is that the velocity field for my advection-diffusion stems 
> from a 
> > Continuous Galerkin solution with another dof handler, formulated using 
> a 
> > FESystem. Everything work well until them. The issue I have is that the 
> > FEInterfaceValues does not seem to want to work with FEValuesExtractors? 
> It 
> > seems like it cannot use the [] operator to extract my velocity values 
> out of 
> > my 4 components (velocity + pressure).
> > 
> > I am sure i'm forgetting something stupid here, but how should I proceed 
> for 
> > vector valued problem using DG?
>
> No, you're not forgetting anything. FEInterfaceValues is still a pretty 
> new 
> class and nobody has ever written the equivalent of the FEValuesViews 
> classes 
> that you get from FEValues when you apply an extractor.
>
> I suspect that the effort would not be huge, and that one could just 
> copy-paste a lot of code from the existing views classes. If you were 
> interested in doing that, I'd be happy to discuss what I think is going to 
> be 
> necessary. But the short answer is really that FEInterfaceValues isn't 
> ready 
> for vector-valued problems at the moment.
>
> Best
> Wolfgang
>
> -- 
> 
> 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/1189c3ca-63e1-4ebf-aace-395747dd4425n%40googlegroups.com.

[deal.II] Using FEInterfaceValues with FESystems?

[blais...@gmail.com]

Dear all,
I hope you are well.
I am currently trying to solve an advection-diffusion equation at very, 
very high Péclet number. I first implemented a GLS-stabilized continuous 
Galerkin solution, it works well, but clearly I think a DG approach would 
be immensely better here.

The issue is that the velocity field for my advection-diffusion stems from 
a Continuous Galerkin solution with another dof handler, formulated using a 
FESystem. Everything work well until them. The issue I have is that the 
FEInterfaceValues does not seem to want to work with FEValuesExtractors? It 
seems like it cannot use the [] operator to extract my velocity values out 
of my 4 components (velocity + pressure).

I am sure i'm forgetting something stupid here, but how should I proceed 
for vector valued problem using DG?
Best
Bruno

-- 
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/26bd805e-4467-43f1-9132-1b61e1880964n%40googlegroups.com.

[deal.II] Open tenure-track faculty position at Polytechnique Montreal

[blais...@gmail.com]

Dear all,
I would like to bring to you attention the following open tenure track 
faculty position at Polyechnique Montréal:
https://www.polymtl.ca/carriere/en/offres-demploi/professor-mechanical-engineering-computational-fluid-dynamics

The position is centered around turbulent CFD in external aerodynamics. I 
have a little bit of a bias, since I am assistant professor there (although 
in another department). It's a great university, with a high tenure success 
rate as well as good collaboration and funding opportunities. Canada also 
has an interesting HPC ecosystem through Compute Canada.

Feel free to apply even if you do not know French. There is dedicated 
support for applicants who do not speak it. You can also reach out to me if 
you have questions!

Best
Bruno

-- 
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/806e4dbf-4f3b-4849-99b3-d3dbdaa0d228n%40googlegroups.com.

Re: [deal.II] Re: Tips on writing "versatile" assembly function

[blais...@gmail.com]

Hi Timo,

I understand. It makes a lot of sense.
Thanks!
Bruno

On Tuesday, January 5, 2021 at 4:34:19 p.m. UTC-5 Timo Heister wrote:

> Hi Bruno,
>
> We mitigate the performance problem by making the decision per cell in 
> ASPECT:
> We have a set of "assemblers" that are executed one after each other
> per cell. This means the vtable access cost is small compared to the
> actual work.
> See
>
> https://github.com/geodynamics/aspect/blob/b9add5f53172aac18bdbb19d14ca266e88c491dd/include/aspect/simulator/assemblers/interface.h#L493-L515
>
> On Tue, Jan 5, 2021 at 4:28 PM blais...@gmail.com  
> wrote:
> >
> > Bruno,
> >
> > Thanks, you are right. As always, measure first and then optimize after. 
> No point in optimising stuff that costs nothing...
> >
> >
> > On Tuesday, January 5, 2021 at 3:15:06 p.m. UTC-5 bruno.t...@gmail.com 
> wrote:
> >>
> >> Bruno,
> >>
> >> If you are worry about the cost of looking up though the vtable, I 
> think that you are stuck using template. So either use 2 or 3 and CRTP. But 
> first of all, I think that you should profile your code and verify that 
> this is a problem. There is no point in spending time refactoring your 
> code, if your are going to gain less than 1%...
> >>
> >> Best,
> >>
> >> Bruno
> >>
> >> On Monday, January 4, 2021 at 3:31:45 PM UTC-5 blais...@gmail.com 
> wrote:
> >>>
> >>> Dear all,
> >>> I wish you all an happy new year!
> >>>
> >>> One problem we always end up facing with FEM problems is that, as 
> program grow, more and more features are added to the equations. This leads 
> to multiple variation of the same equations (for example, Navier-Stokes 
> with Newtonian and non-Newtonian viscosity, etc.). In turn, this leads to 
> assembly functions for the non-linear systems of equations which branch out 
> to multiple possibilities.
> >>>
> >>> I was wondering what is the best approach to deal with multiple 
> "switches" in an assembly function. The naïve approach would be to use if 
> conditions, but I have a feeling that if they appear down in the assembly 
> (for example the loop on dofs), this would lead to significantly higher 
> assembly cost because the loops would spend time just checking if.
> >>>
> >>> From experience, I have seen the following approaches:
> >>> 1- If or switches in the assembly routine. Simplest/most versatile 
> way, but adds significant overhead
> >>> 2- Template the assembly function with the parameters. I think this 
> would lead to zero additional cost, but as the number of parameters grows, 
> this can become more and more complex since the various possibilities have 
> to be known at compile time.
> >>> 3- Use generic interface objects for common elements (for example a 
> viscosity class to calculate viscosity, etc.) and use inheritance to 
> specialise the model. I think this could be inefficient because of the need 
> to extensively look up through the vtable.
> >>>
> >>> What is the general consensus in the deal.II community on this 
> problem? What's the best way to deal with multiple possibilities in the 
> same assembly function? I would be very interested in hearing the 
> perspective of the ASPECT author since it has such a large range of sub 
> models.
> >>>
> >>>
> > --
> > 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+un...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/a501667f-4cb7-4894-9364-fb2eaa47c0ecn%40googlegroups.com
> .
>
>
>
> -- 
> Timo Heister
> http://www.math.clemson.edu/~heister/
>

-- 
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/8748edb0-c096-4830-92e3-4a50baae00e9n%40googlegroups.com.

[deal.II] Re: Tips on writing "versatile" assembly function

[blais...@gmail.com]

Bruno,

Thanks, you are right. As always, measure first and then optimize after. No 
point in optimising stuff that costs nothing...


On Tuesday, January 5, 2021 at 3:15:06 p.m. UTC-5 bruno.t...@gmail.com 
wrote:

> Bruno,
>
> If you are worry about the cost of looking up though the vtable, I think 
> that you are stuck using template. So either use 2 or 3 and CRTP. But first 
> of all, I think that you should profile your code and verify that this is a 
> problem. There is no point in spending time refactoring your code, if your 
> are going to gain less than 1%...
>
> Best,
>
> Bruno
>
> On Monday, January 4, 2021 at 3:31:45 PM UTC-5 blais...@gmail.com wrote:
>
>> Dear all,
>> I wish you all an happy new year!
>>
>> One problem we always end up facing with FEM problems is that, as program 
>> grow, more and more features are added to the equations. This leads to 
>> multiple variation of the same equations (for example, Navier-Stokes with 
>> Newtonian and non-Newtonian viscosity, etc.). In turn, this leads to 
>> assembly functions for the non-linear systems of equations which branch out 
>> to multiple possibilities.
>>
>> I was wondering what is the best approach to deal with multiple 
>> "switches" in an assembly function. The naïve approach would be to use if 
>> conditions, but I have a feeling that if they appear down in the assembly 
>> (for example the loop on dofs), this would lead to significantly higher 
>> assembly cost because the loops would spend time just checking if.
>>
>> From experience, I have seen the following approaches:
>> 1- If or switches in the assembly routine. Simplest/most versatile way, 
>> but adds significant overhead
>> 2- Template the assembly function with the parameters. I think this would 
>> lead to zero additional cost, but as the number of parameters grows, this 
>> can become more and more complex since the various possibilities have to be 
>> known at compile time.
>> 3- Use generic interface objects for common elements (for example a 
>> viscosity class to calculate viscosity, etc.) and use inheritance to 
>> specialise the model. I think this could be inefficient because of the need 
>> to extensively look up through the vtable.
>>
>> What is the general consensus in the deal.II community on this problem? 
>> What's the best way to deal with multiple possibilities in the same 
>> assembly function? I would be very interested in hearing the perspective of 
>> the ASPECT author since it has such a large range of sub models.
>>
>>
>>

-- 
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/a501667f-4cb7-4894-9364-fb2eaa47c0ecn%40googlegroups.com.

[deal.II] Tips on writing "versatile" assembly function

[blais...@gmail.com]

Dear all,
I wish you all an happy new year!

One problem we always end up facing with FEM problems is that, as program 
grow, more and more features are added to the equations. This leads to 
multiple variation of the same equations (for example, Navier-Stokes with 
Newtonian and non-Newtonian viscosity, etc.). In turn, this leads to 
assembly functions for the non-linear systems of equations which branch out 
to multiple possibilities.

I was wondering what is the best approach to deal with multiple "switches" 
in an assembly function. The naïve approach would be to use if conditions, 
but I have a feeling that if they appear down in the assembly (for example 
the loop on dofs), this would lead to significantly higher assembly cost 
because the loops would spend time just checking if.

>From experience, I have seen the following approaches:
1- If or switches in the assembly routine. Simplest/most versatile way, but 
adds significant overhead
2- Template the assembly function with the parameters. I think this would 
lead to zero additional cost, but as the number of parameters grows, this 
can become more and more complex since the various possibilities have to be 
known at compile time.
3- Use generic interface objects for common elements (for example a 
viscosity class to calculate viscosity, etc.) and use inheritance to 
specialise the model. I think this could be inefficient because of the need 
to extensively look up through the vtable.

What is the general consensus in the deal.II community on this problem? 
What's the best way to deal with multiple possibilities in the same 
assembly function? I would be very interested in hearing the perspective of 
the ASPECT author since it has such a large range of sub models.


-- 
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/07ed2353-063b-4dda-b6ec-1cda64b3a539n%40googlegroups.com.

Re: [deal.II] Tips and tricks for functional tests on chaotic systems

[blais...@gmail.com]

There is a Facebook deal.II account? Now I know what to follow :)!
Cheers!
Bruno


On Tuesday, December 29, 2020 at 12:20:15 p.m. UTC-5 Wolfgang Bangerth 
wrote:

> On 12/28/20 10:54 PM, blais...@gmail.com wrote:
> > 
> > If you want to see an animation of DEM done using the deal.II particle 
> > library, you can find one on the following youtube link:
> > https://www.youtube.com/watch?v=jPrxQ3KqNcI=youtu.be
>
> Nice -- that just made it to the deal.II Facebook account :-)
>
> 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 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/7607b1b3-a8f1-48d6-a329-ffb93765f0b7n%40googlegroups.com.

Re: [deal.II] Tips and tricks for functional tests on chaotic systems

[blais...@gmail.com]

Hi Wolfgang,
Thank you for the suggestion. I did not think about it, but testing 
statistical properties (center of mass, average velocity, total kinetic 
energy) seems like a very sound idea!

If you want to see an animation of DEM done using the deal.II particle 
library, you can find one on the following youtube link:
https://www.youtube.com/watch?v=jPrxQ3KqNcI=youtu.be

This is just an illustration, but it actually scales to millions of 
particles at the moment.

On Tuesday, December 29, 2020 at 12:13:20 a.m. UTC-5 Wolfgang Bangerth 
wrote:

>
> Hi Bruno,
>
> > We are currently working on our DEM simulation engine using deal.II 
> particles 
> > features. DEM lead to very chaotic systems (with positive Lyapunov 
> exponents, 
> > like in MD), which means that slight discrepancies in floating point 
> numbers 
> > can lead to exponentially different results. You can imagine for example 
> that 
> > if a particle is to fall exactly on top of another, a slight difference 
> in 
> > round-off error can lead to the particle sliding to the right or to the 
> left 
> > of the other particle. Consequently, very small differences accumulate 
> and 
> > lead to drastically different results.
> > 
> > Right now, we are testing everything using numdiff within a ctest 
> framework 
> > identical to deal.II. However, since we are comparing text files with 
> > particles positions and velocities, the tests end up being extremely 
> fragile 
> > because they depend on the compiler version and MPI library being used 
> (I guess?).
> > 
> > I was wondering if any of you had experience on what would be the best 
> way to 
> > write functional tests that test the full code in the context of systems 
> which 
> > show highly chaotic behavior like this? Right now we try to test for 
> very 
> > small time, thus ensuring that differences don't have the time to 
> propagate, 
> > but this is becoming more and more fragile and sometimes tests will 
> crash on a 
> > peculiar machine, yet work on 95% of the other ones (such as our github 
> actions).
>
> Interesting :-)
>
> I think that conceptually, you probably do want to test certain aspects of 
> your code in this deterministic way. For example, if you want to check the 
> correctness of the particle trajectory integrator, you can do that with a 
> small number of particles whose trajectories stay well away from chaotic 
> points.
>
> But there are of course also other aspects that really are chaotic and 
> that 
> you also want to test. In those cases, you need to identify the 
> statistical 
> properties that *do* behave deterministically. For example, the motion of 
> individual stars in globular star clusters is likely chaotic, but the 
> motion 
> of the center of mass, or the evolution of the angular momentum and total 
> energy is not. These are things you can compute and output and they should 
> be 
> comparable among compilers and platforms. If you have enough particles, 
> you 
> could also consider things such as kernel density estimates of particle 
> densities, momentum densities, etc.
>
> 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/160fbc79-32e5-4179-b9de-b9ea7a290ac0n%40googlegroups.com.

[deal.II] Tips and tricks for functional tests on chaotic systems

[blais...@gmail.com]

Dear all,
I hope you are well.
It is me again pestering you all with questions or looking for advice :).

We are currently working on our DEM simulation engine using deal.II 
particles features. DEM lead to very chaotic systems (with positive 
Lyapunov exponents, like in MD), which means that slight discrepancies in 
floating point numbers can lead to exponentially different results. You can 
imagine for example that if a particle is to fall exactly on top of 
another, a slight difference in round-off error can lead to the particle 
sliding to the right or to the left of the other particle. Consequently, 
very small differences accumulate and lead to drastically different results.

Right now, we are testing everything using numdiff within a ctest framework 
identical to deal.II. However, since we are comparing text files with 
particles positions and velocities, the tests end up being extremely 
fragile because they depend on the compiler version and MPI library being 
used (I guess?).

I was wondering if any of you had experience on what would be the best way 
to write functional tests that test the full code in the context of systems 
which show highly chaotic behavior like this? Right now we try to test for 
very small time, thus ensuring that differences don't have the time to 
propagate, but this is becoming more and more fragile and sometimes tests 
will crash on a peculiar machine, yet work on 95% of the other ones (such 
as our github actions).

Thanks and I wish you all great holidays!
Bruno

-- 
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/22c85579-d403-4431-b150-e0520271df75n%40googlegroups.com.

[deal.II] Re: Making ParticlesHandler work with dealii::Triangulation and mesh refinement/coarsening

[blais...@gmail.com]

Dear Wu,
Have you tried without the dynamic cast? Can you bind the callback of a 
regular triangulation?
I must admit I have never tried to use particles with regular triangulation 
(and I think that outside of step-19, not much people have done it ).


On Tuesday, December 15, 2020 at 4:49:39 p.m. UTC-5 WU, Qihang wrote:

> Hi deal.II Community,
>
> I am new to the library and I'm trying to implement a prototype Stokes 
> flow solver with tracer particles using shared memory computing. The 
> overall procedure is something like:
>
> 1) Solve velocities and pressure analogous to Step-22.
> 2) Execute coarsening and refinement
> 3) Interpolate velocities to particles and move particles.
>
> What I found is after grid coarsening, the particles which originally 
> belong to the finer grid loses its host cell and an exception is thrown 
> from ParticleAccessor::get_surrounding_cell().
>
> I read through step-19 on Github. From my understanding the implementation 
> there does not involve AMR and therefore such problems do not occur. I also 
> consulted step-68 and 70. Those two implementations use 
> parallel::distributed::Triangulation and attach pre- and post-refinement 
> callback functions to save and reload particles. However in these functions 
> the dynamic_cast from Triangulation to p::d::Triangulation is invalid and 
> returns a nullptr.
>
> My question is am I correct to assume that the library does not yet fully 
> support particles on dealii::Triangulation with AMR? If yes can I ask for 
> some guidance on how to implement it myself? One naive way out seems to be 
> to store and reload procedure as is done in the library for 
> p::d::Triangulation, but is it too costly?
>
> I really appreciate your time and help.
>
> Cheers,
> Qihang.
>
>
>
>
>

-- 
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/1838b606-b9d3-4508-9904-5ec11493921dn%40googlegroups.com.

Re: [deal.II] Re: Saving particles for checkpointing

[blais...@gmail.com]

Awesome.
It works perfectly
Thank you all :)!


On Wednesday, December 9, 2020 at 8:10:13 p.m. UTC-5 Wolfgang Bangerth 
wrote:

> On 12/9/20 5:32 PM, blais...@gmail.com wrote:
> > I have one tiny question actually.
> > In all tests, the std::ostringstream oss which contains some information 
> about 
> > the number of particles and the data being serialized is kept.
> > Generally, I guess this should be written to an auxiliary file, then 
> re-read 
> > before deserialization can occur?
>
> Yes, precisely. In fact, instead of a std::ostringstring, when you write 
> to 
> file you might as well have directly given a std::ofstream.
>
> That that data could be written to a file is not important for the test, 
> though, and so it doesn't do that.
>
> 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/87d7f871-1bc9-420d-9da7-c5ba69acfedan%40googlegroups.com.

[deal.II] Re: Saving particles for checkpointing

[blais...@gmail.com]

I have one tiny question actually.
In all tests, the std::ostringstream oss which contains some information 
about the number of particles and the data being serialized is kept.
Generally, I guess this should be written to an auxiliary file, then 
re-read before deserialization can occur?



On Wednesday, December 9, 2020 at 7:13:08 p.m. UTC-5 blais...@gmail.com 
wrote:

> I think they will! I feel kind-off dumb not having realized that :)
> Thanks!
> Bruno
>
>
> On Wednesday, December 9, 2020 at 6:06:17 p.m. UTC-5 peterrum wrote:
>
>> Do the following links help?
>> - 
>> https://github.com/dealii/dealii/blob/master/tests/serialization/particle_handler_01.cc
>> - 
>> https://github.com/dealii/dealii/blob/master/tests/serialization/particle_handler_02.cc
>>
>> Peter
>>
>> On Wednesday, 9 December 2020 at 23:15:09 UTC+1 blais...@gmail.com wrote:
>>
>>> Dear all, I hope you are well.
>>> I am trying to add checkpointing in our particle code. Particles do not 
>>> have a save function, but they have a serialize function, which I think 
>>> would be exactly what I need.
>>> However, the function is not documented. It takes as an argument 
>>> something of class Archive, which I could not find any information on.
>>> I also grepped all over the tests, but I could not find a usage of this 
>>> function.
>>>
>>> https://www.dealii.org/current/doxygen/deal.II/classParticles_1_1ParticleHandler.html#a877e1aac8ef0ad6fa85ed400bf71eb1c
>>>
>>> Would anybody have a quick tutorial or example on how this function 
>>> could be used for checkpoint the particle_handler and the properties of the 
>>> particles?
>>> Thank you so much :)!
>>> Bruno
>>>
>>>

-- 
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/9e3ea43b-ab68-44e9-b85d-c0e47069e848n%40googlegroups.com.

[deal.II] Re: Saving particles for checkpointing

[blais...@gmail.com]

I think they will! I feel kind-off dumb not having realized that :)
Thanks!
Bruno


On Wednesday, December 9, 2020 at 6:06:17 p.m. UTC-5 peterrum wrote:

> Do the following links help?
> - 
> https://github.com/dealii/dealii/blob/master/tests/serialization/particle_handler_01.cc
> - 
> https://github.com/dealii/dealii/blob/master/tests/serialization/particle_handler_02.cc
>
> Peter
>
> On Wednesday, 9 December 2020 at 23:15:09 UTC+1 blais...@gmail.com wrote:
>
>> Dear all, I hope you are well.
>> I am trying to add checkpointing in our particle code. Particles do not 
>> have a save function, but they have a serialize function, which I think 
>> would be exactly what I need.
>> However, the function is not documented. It takes as an argument 
>> something of class Archive, which I could not find any information on.
>> I also grepped all over the tests, but I could not find a usage of this 
>> function.
>>
>> https://www.dealii.org/current/doxygen/deal.II/classParticles_1_1ParticleHandler.html#a877e1aac8ef0ad6fa85ed400bf71eb1c
>>
>> Would anybody have a quick tutorial or example on how this function could 
>> be used for checkpoint the particle_handler and the properties of the 
>> particles?
>> Thank you so much :)!
>> Bruno
>>
>>

-- 
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/8b8fb15a-4ba7-40dd-9cfe-151677b307e5n%40googlegroups.com.

[deal.II] Saving particles for checkpointing

[blais...@gmail.com]

Dear all, I hope you are well.
I am trying to add checkpointing in our particle code. Particles do not 
have a save function, but they have a serialize function, which I think 
would be exactly what I need.
However, the function is not documented. It takes as an argument something 
of class Archive, which I could not find any information on.
I also grepped all over the tests, but I could not find a usage of this 
function.
https://www.dealii.org/current/doxygen/deal.II/classParticles_1_1ParticleHandler.html#a877e1aac8ef0ad6fa85ed400bf71eb1c

Would anybody have a quick tutorial or example on how this function could 
be used for checkpoint the particle_handler and the properties of the 
particles?
Thank you so much :)!
Bruno

-- 
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/11a1304d-fd8c-4ea1-8fb8-81e52ae748e8n%40googlegroups.com.

Re: [deal.II] Suggestions for "cheap" distributed preconditioner for transient systems?

[blais...@gmail.com]

Thank you all for the help :).
This is always a bit of a lesson in humility where I realise there is just 
so much I don't know, and how much out there there is still to learn :)!.


On Monday, December 7, 2020 at 11:52:51 a.m. UTC-5 Wolfgang Bangerth wrote:

> On 12/7/20 6:19 AM, blais...@gmail.com wrote:
> > 
> > How come you get away with only assembling the matrix every 3-5 time 
> steps?
> > Are you treating advection explicitly?
> > 
> > We get off by assembling the matrix every N time-steps for two main 
> reasons:
> > - We use SDIRK which has a constant diagonal for all stages, hence this 
> part 
> > of the matrix does not change significantly
> > - We are willing to sacrifice one non-linear iteration there and there, 
> at the 
> > cost of less assembly. The idea is that we use an exact jacobian when we 
> > assemble the matrix, but then we let it become innacurate as we continue 
> > iterating, while just updating the rhs. This is not a good approach when 
> the 
> > time-step is large, but when the time-step is small (say CFL<1), it 
> really 
> > does not affect significantly the number of newton iterations. 
> Consequently, 
> > we can update the jacobian matrix every 3 to 5 time-steps or so. This is 
> just 
> > an indication, generally we update it as soon as a non-linear step has 
> not 
> > lead to a decrease of more than 10x of the residual, meaning that our 
> Newton 
> > method is becoming inefficient.
>
> Nice approach!
>
>
> > I'm also curious about what the matrix you use looks like. It must be
> > something like
> > A B
> > B^T C
> > What terms are in A,B,C?
> > 
> > It has exactly this shape. The full weak form and some results are 
> detailed in 
> > : https://www.sciencedirect.com/science/article/pii/S2352711020302922
> > A is momentum + SUPG
> > C is the PSPG block. In essence it looks very much like a stiffness 
> matrix 
> > weighted by the stabilization parameter.  Hence, I really don't think it 
> is 
> > "well conditioned".
>
> Timo and Martin have already answered the question that underlaid why I 
> asked 
> about the block structure. In practice, you can't get good preconditioners 
> if 
> you don't exploit what a matrix corresponds to. ILU doesn't work well for 
> this 
> reason, but if you can decompose a matrix into its blocks, you can get 
> optimal 
> preconditioners for each block (say, the top left A block, given what it 
> represents -- if you resolve the length scales of advection, i.e., if your 
> cell Peclet number is less than 1, then it's essentially an elliptic 
> operator 
> for which you can apply multigrid methods). Then you build your overall 
> preconditioner from preconditioners for each block separately.
>
> I second the suggestion of the book by Elman, Silvester, and Wathen. I 
> would 
> also point you to step-22. The implementation in the actual program is 
> more 
> for illustrative purposes of what one can do, but I would suggest you 
> specifically read the section in the "Possibilities for extensions" that 
> discusses the Silvester/Wathen preconditioner which is probably close to 
> optimal. (It uses a mass matrix for the Schur complement, and that can be 
> done 
> better using the BTFB method, but I think it points you in the right 
> direction).
>
> Completely separately, one of the things Timo and I played around with in 
> ASPECT a long time ago is whether to make some terms in the equation 
> explicit 
> or implicit. We had originally made advection explicit, because that then 
> leads to a symmetric system matrix and we thought that that would be a 
> more 
> efficient way to solve the linear system. And that's true, symmetric 
> systems 
> are faster to solve. But it required us to have a substantially smaller 
> time 
> step, and in the end we realized that the overall time spent is (time per 
> time 
> step) * (number of time steps) and that by doing everything implicit, we 
> could 
> increase the time step size by 10x whereas the cost for solving the linear 
> systems only increased by 2x, so the made the whole simulation cheaper by 
> 5x.
>
> I think that from your description you're already doing everything 
> implicitly, 
> but it's worth thinking about these kinds of trade-offs anyway if you 
> currently have anything that limits your time step size.
>
> Best
> W.
>
>
> -- 
> 
> Wolfgang Bangerth email: bang...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
>

-- 
The deal.II project is located at http://w

Re: [deal.II] Suggestions for "cheap" distributed preconditioner for transient systems?

[blais...@gmail.com]

Dear Timo and Martin,
Thank you very much for the help and advice.
I'll definitely take the time to read the references of Martin and look 
into what you are suggesting. Clearly, I need to exploit the structure of 
the matrix significantly more to be able to extract more performance out of 
the solver. Thank you very much your time:). Now it's back to reading! The 
complexity of these equations never ceases to amaze me.
Take care
Bruno


On Monday, December 7, 2020 at 9:27:09 a.m. UTC-5 Timo Heister wrote:

> > If I understand correctly, you mean formulating the problem using a 
> BlockMatrix and a BlockVector, then preconditioning each matrix of the 
> block independently?
>
> Correct. You perform a block LU decomposition by hand and use that as
> your preconditioner. Then approximate the blocks as best as you can.
> The advantage is that you can exploit PDE specifics:
> - lumping of mass matrices
> - AMG/GMG for laplace-like operators
> - ILU/Jacobi for mass matrix-like operators
> - spectrally-equivalent matrices to approximate Schur complements
> - and more
>
> We have many tutorial steps that teach this (but not precisely for
> your problem).
>
> > I guess this would be best achieved using the linear operators within 
> deal.II right?
>
> Not necessarily. See step-55 and step-57 for example. The linear
> operator framework helps, especially to define implicit operators
> (step-20), but is not required.
>
> > What would be the added benefit of that? I would presume that since each 
> block have more "coherent units", this would at least to a better 
> conditioning of the final system, but is there anything else there?
>
> I doubt you can get optimal preconditioners (in the sense of cost
> independent of h and other problem parameters) without exploiting
> PDE-specifics.
>
>
> -- 
> Timo Heister
> http://www.math.clemson.edu/~heister/
>

-- 
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/f7fac411-ee55-4988-b42d-e4bf81c793b1n%40googlegroups.com.

Re: [deal.II] Suggestions for "cheap" distributed preconditioner for transient systems?

[blais...@gmail.com]

Dear Timo,
thank you for your answer and your time :)

On Sunday, December 6, 2020 at 9:04:24 p.m. UTC-5 Timo Heister wrote:

> > The task generally contain on the order of 50M to 100M DOFs and are 
> transient DNS problems. 
>
> With this you are likely at a point where factorizations (even ILU) 
> not work very well. Even if you can afford a Block ILU, you likely run 
> on 100+ cores, which means the quality of the preconditioner will 
> deteriorate quite a lot just based on the number of processors. You 
> likely need something that puts more effort into the parallel aspect. 
>

I fully agree. This is the part where my knowledge is extremely limited. I 
can clearly see that my strategy is becoming poorer and poorer as my number 
of core and the size of my system increases. To be honest, this is a first 
venture for me in terms of looking at problems this size. In the past in my 
career I was always in the early 1-2M cells, whereas here we are talking 
about 50M cells and traditional approach quickly become inefficient.

 

>
> > Our solver : Either GMRES or BiCGStab. In our case it seems GMRES is a 
> bit faster (around 20%) because the iterations are cheaper. I have tried 
> all of the solvers in the TrilinosWrappers except FGMRES actually. 
>
> My general advice is to work on the preconditioner to have a method in 
> the 10-40 iterations range. Then, it doesn't really matter which 
> Krylov method you use. Just use FGMRES (if you need flexibility), CG 
> (for SPD), MINRES (for symmetric), or GMRES (for everything else). 
> Switching between different Krylov methods is unlikely to make a big 
> difference unless you are in the 100k+ core range or need too many 
> iterations. 
>

Understood. Let's say that right now we are more in the 40-80 iterations 
range, making me think that we could be more efficient.
 

>
> > Our current preconditioner : ILU(0) 
> > Element order : Q2-Q2, Q3-Q3 or Q4-Q4. 
>
> Are you just applying ILU to the whole system? My general advice is to 
> exploit the block structure of your PDE first and then apply ILU or 
> AMG to individual blocks. Time dependent Navier-Stokes with small time 
> steps is a relatively easy case. Let me know if you want more details. 
>

Yes, I am applying ILU to the whole system, without anything else really. I 
think this is relatively traditional in GLS and VMS approaches (although I 
would not be able to say if that is a good or a bad thing).

If I understand correctly,  you mean formulating the problem using a 
BlockMatrix and a BlockVector, then preconditioning each matrix of the 
block independently?
I guess this would be best achieved using the linear operators within 
deal.II right?
What would be the added benefit of that? I would presume that since each 
block have more "coherent units", this would at least to a better 
conditioning of the final system, but is there anything else there?
Is there any literature or elements on this? I feel like linear solver 
aspect is such a critical element of a good Navier-Stokes solver, but I 
struggle to find easy/accessible literature on the topic. This is where my 
Chemical Engineering background makes me feel like I am biting more than I 
can chew :).

Thank you very much for your time. I really appreciate it.


 

>
>
> -- 
> Timo Heister 
> http://www.math.clemson.edu/~heister/ 
>

-- 
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/91da12d7-3da0-4a8e-9f59-8b273b4e5e70n%40googlegroups.com.

Re: [deal.II] Suggestions for "cheap" distributed preconditioner for transient systems?

[blais...@gmail.com]

Dear Wolgang, thank you for the answers

On Sunday, December 6, 2020 at 8:00:09 p.m. UTC-5 Wolfgang Bangerth wrote:

> On 12/6/20 12:27 PM, blais...@gmail.com wrote: 
> > 
> > In this case, even using ILU(1) is extremely expensive (e.g. it takes 2X 
> more 
> > time than to assemble the matrix and it really doubles up the iteration 
> time). 
> > Consequently, we are using ILU(0), which in the present case is 
> performing 
> > relatively well (say between 40-100 iterations per newton step). I was 
> > wondering if there were any other suggestions in terms of preconditioner 
> that 
> > we could use? 
> > 
> > Our system : GLS stabilized Navier-Stokes, monolithic matrix formulation 
> > (single matrix for u,v,w,p). The matrix is non-symmetric. 
> > Our solver : Either GMRES or BiCGStab. In our case it seems GMRES is a 
> bit 
> > faster (around 20%) because the iterations are cheaper. I have tried all 
> of 
> > the solvers in the TrilinosWrappers except FGMRES actually. 
> > Our current preconditioner : ILU(0) 
> > Library used : Trilinos through the deal.II wrappers 
> > Element order : Q2-Q2, Q3-Q3 or Q4-Q4. 
> > 
> > Any suggestions would be appreciated. I am doing all I can right now to 
> > speed-up matrix assembly, but in general we only need to assemble the 
> matrix 
> > every 3-5 time steps, so I am just trying to find a good compromise 
> between a 
> > good preconditioner that is not crazy expensive. Would I be better to 
> accept 
> > having a poorer jacobian matrix, use a more expensive preconditioner and 
> > keeping it for a longer time (say 10-20 time-steps)? 
>
> Have you played with the trade-off of having a more expensive 
> preconditioner 
> but building it less often? For example, using ILU(1) instead of ILU(0), 
> but 
> only build it every few time steps?  


> How come you get away with only assembling the matrix every 3-5 time 
> steps? 
> Are you treating advection explicitly? 
>
We get off by assembling the matrix every N time-steps for two main reasons:
- We use SDIRK which has a constant diagonal for all stages, hence this 
part of the matrix does not change significantly
- We are willing to sacrifice one non-linear iteration there and there, at 
the cost of less assembly. The idea is that we use an exact jacobian when 
we assemble the matrix, but then we let it become innacurate as we continue 
iterating, while just updating the rhs. This is not a good approach when 
the time-step is large, but when the time-step is small (say CFL<1), it 
really does not affect significantly the number of newton iterations. 
Consequently, we can update the jacobian matrix every 3 to 5 time-steps or 
so. This is just an indication, generally we update it as soon as a 
non-linear step has not lead to a decrease of more than 10x of the 
residual, meaning that our Newton method is becoming inefficient.


 

>
> I'm also curious about what the matrix you use looks like. It must be 
> something like 
> A B 
> B^T C 
> What terms are in A,B,C? 
>
It has exactly this shape. The full weak form and some results are detailed 
in : https://www.sciencedirect.com/science/article/pii/S2352711020302922
A is momentum + SUPG
C is the PSPG block. In essence it looks very much like a stiffness matrix 
weighted by the stabilization parameter.  Hence, I really don't think it is 
"well conditioned".


> Best 
> Wolfgang 
>
Thank you for your time. As always, I really appreciate this community :)!

 

>
> -- 
>  
> 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/77c9d3ee-73e1-430a-8c3f-9f00dcb2b141n%40googlegroups.com.

[deal.II] Suggestions for "cheap" distributed preconditioner for transient systems?

[blais...@gmail.com]

Hello all,
I hope you are all well. This is not strictly a deal.II question, but I 
thought I could benefit for the huge amount of expertise present on this 
board.
I am currently launching large (at least from my POV) tasks on our HPC 
cluster. The task generally contain  on the order of 50M to 100M DOFs and 
are transient DNS problems.

Right now we are solving the Navier-Stokes equations in a GLS formulation. 
For steady-state problems,  it is reasonably pertinent to use expensive 
preconditioners (like AMG with ILU-smoother/coarsener or straight  ILU(1) 
or ILU(2)) because we do not do a large number of iterations. However, in 
the present case we wish to use a very small time-step (even though we are 
using a high-order L-Stable SDIRK33 time integration).

In this case, even using ILU(1) is extremely expensive (e.g. it takes 2X 
more time than to assemble the matrix and it really doubles up the 
iteration time). Consequently, we are using ILU(0), which in the present 
case is performing relatively well (say between 40-100 iterations per 
newton step). I was wondering if there were any other suggestions in terms 
of preconditioner that we could use?

Our system : GLS stabilized Navier-Stokes, monolithic matrix formulation 
(single matrix for u,v,w,p). The matrix is non-symmetric.
Our solver : Either GMRES or BiCGStab. In our case it seems GMRES is a bit 
faster (around 20%) because the iterations are cheaper. I have tried all of 
the solvers in the TrilinosWrappers except FGMRES actually.
Our current preconditioner : ILU(0)
Library used : Trilinos through the deal.II wrappers
Element order : Q2-Q2, Q3-Q3 or Q4-Q4. 

Any suggestions would be appreciated. I am doing all I can right now to 
speed-up matrix assembly, but in general we only need to assemble the 
matrix every 3-5 time steps, so I am just trying to find a good compromise 
between a good preconditioner that is not crazy expensive. Would I be 
better to accept having a poorer jacobian matrix, use a more expensive 
preconditioner and keeping it for a longer time (say 10-20 time-steps)?

-- 
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/773f2720-0443-4762-b8dc-46814c4b5ae9n%40googlegroups.com.

Re: [deal.II] Clearing a particle properties without getting properties for each particle

[blais...@gmail.com]

Hello Shahab,
I would wait before trying to do some changes. Rene has started looking 
more deeply into the particle structure (see 
: https://github.com/dealii/dealii/pull/11314) and this will, most likely, 
fix your problem.


On Friday, December 4, 2020 at 8:18:11 a.m. UTC-5 shahab.g...@gmail.com 
wrote:

> 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/5e92a68f-bd8c-4877-bfad-047b8a4fc86cn%40googlegroups.com.

Re: [deal.II] Re: Pressure-correction scheme: Behaviour of the H1 norm on the Taylor-Green vortex

[blais...@gmail.com]

Hello Jose,
I hope you are well.
I was wondering if you had managed to get your code on github or any 
sharing service? I would be really interested in comparing how it behaves 
with monolothic FEM approaches. This is something that is very relevant to 
our research (and on which I would be glad to collaborate :) )


On Saturday, October 24, 2020 at 6:23:55 a.m. UTC-4 jose.a...@gmail.com 
wrote:

> Hello Wolfgang, Marthin, Bruno, Richard and Timo,
>  
>
>> 'm not entirely clear about what your question is. Are you seeing 
>> convergence 
>> rates that are too low or too large? It is not uncommon to have cases 
>> where a 
>> scheme converges too fast (the convergence rate is too large); this is 
>> typically the case because the solution has a symmetry.
>>
>> Best
>>   W.
>
>
> Apologies for not explaining myself clearer. I will try it again:
> From my understanding, the lowest bound of the error on each norm is set 
> either by the spatial or the temporal discretization. I was kind of 
> expecting that the L2- and H1-Norms share a similar spatial and time 
> dependence, i.e. that each field reaches its lowest bound simultaneously, 
> and that they do so with a similar convergence rate evolution. Stated 
> differently, they start with an order of convergence which remains constant 
> for a given time step range. After reaching a small time step size, the 
> convergence order tends to zero as the lowest bound of the error is reached.
> From the tests' results I can see that H1-Norm of the pressure has a 
> considerably stronger spatial dependence than the velocity, as it reaches 
> its lowest bound while the velocity still has a constant convergence order. 
> This behaviour is also seen in the L2- and Linfty-Norm but in a much more 
> milder scale, as seen in the spatial convergence test. My question is if 
> this stronger spatial dependency of the pressure is problem dependent or if 
> it is intrinsic to the pressure-correction scheme.
>
> While I have not experimented in detail with the step-35 program, we have 
>> done extensive studies on similar problems in 
>> https://doi.org/10.1016/j.jcp.2017.09.031 (or 
>> https://arxiv.org/abs/1706.09252 for an earlier preprint version of the 
>> same manuscript) including the pressure correction scheme. While the 
>> spatial discretization is DG where some of the issues are , the experience 
>> from our experiments suggests that the pressure correction scheem should 
>> not behave too differently from other time discretization schemes with 
>> similar ingredients (say BDF-2 on the fully coupled scheme). In other 
>> words, I would expect second order convergence in the pressure for 
>> Taylor-Hood elements. I should note that there are some subtle issues with 
>> boundary conditions in projection schemes, so I cannot exclude some hidden 
>> problems with the step-35 implementation or the way you set up the 
>> experiments.
>>
>> Best,
>> Martin
>>
> Thanks for the manuscript, there I notice that the results shown are those 
> of the behaviour of the L2-Norm. My finite element implementation behaves 
> similarly in the L2-Norm to the convergence rates in your paper (BFD2 leads 
> to a 2nd order convergence on both velocity and, for the most part, on 
> pressure). Did you also analyse the H1-Norm by any chance? There is where I 
> see the stronger spatial dependency of the pressure.
> On another note, it caught my eye that you split the Neumann boundary 
> conditions. I have not done tests with them yet, but what is the benefit of 
> doing this or why is it necessary? Furthermore, my next step would be the 
> DFG 2D-2 benchmark. There, you computed the traction force using the 
> symmetric gradient instead of the normal gradient. While your formulation 
> would be for me the correct formulation, as the stress tensor is so 
> defined, on the benchmark papers they use the normal gradient. This has 
> caused me some confusion, as to which formulation should I implement for 
> the benchmark.
>
> Hello Jose,
>> I wish I could help, but I second Wolfgang's question.
>> Is your code available somewhere? I would be glad to take a look at it 
>> and compare the solutions for the same problems using different 
>> formulations. I would expect that if you fix the issue with boundary 
>> conditions (those described in the Guermond paper, that is the  "pressure 
>> boundary layer") then you would recover exactly what you should get with 
>> traditional schemes using Taylor-Hood element (as Martin discussed).
>>
>
> I tried reformulating the question above. Hopefully it is clearer now. I 
> will clean the code up and get back to you. The pressure-correction scheme 
> I am using is the incremental rotational, which has the smallest error 
> caused due to the boundary layer. Could the boundary layer in this case 
> still cause such a strong influence? 
>
> if the velocity error you have is low enough, the somewhat 
>> time-independent PPE you solve given that velocity,
>> you 

Re: [deal.II] Re: Pressure-correction scheme: Behaviour of the H1 norm on the Taylor-Green vortex

[blais...@gmail.com]

>
> Hello Jose,
>> I wish I could help, but I second Wolfgang's question.
>> Is your code available somewhere? I would be glad to take a look at it 
>> and compare the solutions for the same problems using different 
>> formulations. I would expect that if you fix the issue with boundary 
>> conditions (those described in the Guermond paper, that is the  "pressure 
>> boundary layer") then you would recover exactly what you should get with 
>> traditional schemes using Taylor-Hood element (as Martin discussed).
>>
>
> I tried reformulating the question above. Hopefully it is clearer now. I 
> will clean the code up and get back to you. The pressure-correction scheme 
> I am using is the incremental rotational, which has the smallest error 
> caused due to the boundary layer. Could the boundary layer in this case 
> still cause such a strong influence? 
>

The TGV case you are simulating only has periodic boundary conditions. 
Artificial pressure boundary layer only appear close to walls where you 
apply a boundary condition on the pressure correction (this is discussed in 
the Guermond paper). If you do not have a wall (or any Dirichlet BC on the 
velocity), you should not get any artificial pressure boundary layer. If 
you are seeing the introduction of an additionnal error in time, it means 
it is introduce by the corrector step, but it is not related to the 
pressure boundary layer.
Otherwise, I second Timo's answer on the convergence of the error.

>From my experience, the best way to analyze the TGV is to try to decouple 
the errors in time and space as much as possible by analyzing the evolution 
of the error in time with a large time step and a very fine mesh and 
analyzing the error in space with a very fine time-step and coarser meshes. 
Otherwise the two errors overlap and it is very hard to draw any sort of 
meaningful conclusions. This is especially true if you use high-order in 
time (BDF2, BDF3, SDIRK22, etc.).

 

-- 
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/d9d3359a-c3f2-4e1c-a7b1-69853afc0414n%40googlegroups.com.

[deal.II] Re: Pressure-correction scheme: Behaviour of the H1 norm on the Taylor-Green vortex

[blais...@gmail.com]

Hello Jose,
I wish I could help, but I second Wolfgang's question.
Is your code available somewhere? I would be glad to take a look at it and 
compare the solutions for the same problems using different formulations. I 
would expect that if you fix the issue with boundary conditions (those 
described in the Guermond paper, that is the  "pressure boundary layer") 
then you would recover exactly what you should get with traditional schemes 
using Taylor-Hood element (as Martin discussed).

On another note, I remember having a discussion about this with Timo 
Heister at the deal.II workshop in 2019. Maybe Timo has ideas on this? I 
know he is quite the expert on algorithms to solve the Stokes / 
Navier-Stokes equations (e.g. his paper on the grad-div scheme, etc.)

Sorry for not being to help more.
Best
Bruno


On Sunday, October 18, 2020 at 12:21:21 p.m. UTC-4 jose.a...@gmail.com 
wrote:

>
> Hello everyone,
>
> I am working on a parallel solver based upon the incremental rotational 
> pressure-scheme  as seen in the overview paper 
> 
>  
> of Guermond and implemented in step-35 
> .  To verify 
> the code, the following problems were replicated
>
>- Numerical test proposed in section 3.7.2 of Guermond's paper. It is 
>based on the method of manufactured solutions. The domain is the unit 
>square and a circle of radius 0.5. Dirichlet boundary conditions are 
>imposed on the whole boundary for the velocity. The pressure field is 
>constrained by setting its mean value to zero.
>
>
>- The Taylor-Green vortex. The domain is the square (0,1)^2. The 
>velocity and pressure field are constrained by periodic boundary 
>conditions. Furthermore, the pressure field is constrained by setting its 
>mean value to zero.
>
> In order to compare the numerical pressure solution to its analytical 
> counterpart, the mean value of the numerical pressure field is made to 
> match that of the analytical one at the end of each time step.
>
> The results for the Guermond's numerical tests for the square domain
>
>Velocity convergence table
>
> ==
> leveldt cells dofs   hmax   L2   
>   H1 Linfty   
> 7 1.00e-01  8572 132098 1.10e-02 8.557567e-03 -
> 6.456461e-02  -   1.103922e-02 - 
> 7 2.50e-02  8572 132098 1.10e-02 5.354964e-04 -2.00 5.090698e-03 -1.83 
> 6.822255e-04 -2.01 
> 7 6.25e-03  8572 132098 1.10e-02 3.358435e-05 -2.00 4.221552e-04 -1.80 
> 4.245914e-05 -2.00 
> 7 1.56e-03  8572 132098 1.10e-02 2.105764e-06 -2.00 3.632448e-05 -1.77 
> 2.656204e-06 -2.00 
>
>Pressure convergence table
>
> ==
> leveldt cells   dofs   hmax   L2   
>   H1 Linfty   
> 7 1.00e-01  8572 16641 1.10e-02 5.543160e-03 -2.687030e-02 
> -3.649990e-02 - 
> 7 2.50e-02  8572 16641 1.10e-02 3.394874e-04 -2.01 3.684615e-03 -1.43 
> 4.209359e-03 -1.56 
> 7 6.25e-03  8572 16641 1.10e-02 2.126561e-05 -2.00 2.738788e-03 -0.21 
> 3.958393e-04 -1.71 
> 7 1.56e-03  8572 16641 1.10e-02 3.049911e-06 -1.40 2.727803e-03 -0.00 
> 2.751900e-05 -1.92 
>
> and for the circle domain
>
>Velocity convergence table
>
> ==
> leveldt cells  dofs  hmax  L2 
>  H1Linfty   
> 6 1.00e-01 10979 164354 1.34e-02 7.593191e-03 -5.404824e-02   
>   -9.465067e-03 - 
> 6 2.50e-02 10979 164354 1.34e-02 4.879026e-04 -1.98 4.298417e-03 -1.83 
> 6.072627e-04 -1.98 
> 6 6.25e-03 10979 164354 1.34e-02 3.069737e-05 -2.00 3.539538e-04 -1.80 
> 3.808221e-05 -2.00 
> 6 1.56e-03 10979 164354 1.34e-02 1.926069e-06 -2.00 3.267549e-05 -1.72 
> 2.500277e-06 -1.96 
>
>Pressure convergence table
>
> ==
> leveldt cells  dofs  hmax  L2 
>  H1Linfty   
> 6 1.00e-01 10979 20609 1.34e-02 2.855089e-03 -1.235457e-02 
> -7.053574e-03 - 
> 6 2.50e-02 10979 20609 1.34e-02 1.983995e-04 -1.92 2.829075e-03 -1.06 
> 4.839667e-04 -1.93 
> 6 6.25e-03 10979 20609 1.34e-02 1.308016e-05 -1.96 2.705119e-03 -0.03 
> 3.305446e-05 -1.94 
> 6 1.56e-03 10979 20609 1.34e-02 3.290324e-06 -1.00 

Re: [deal.II] Clearing a particle properties without getting properties for each particle

[blais...@gmail.com]

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?

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.




On Monday, October 19, 2020 at 10:11:33 a.m. UTC-4 Wolfgang Bangerth wrote:

> On 10/19/20 4:58 AM, blais...@gmail.com wrote:
> > The issue is that this code is being called a lot (in our case every 
> > iteration, so 100k to 10M times) and each iteration is very fast (1k 
> iteration 
> > is a second or so). Consequently, we've had some severe issue when 
> timing in 
> > parallel.
> > If nothing is wrong with the code I guess what I am seeing is just the 
> cost of 
> > iterating through the particle data structure and valgrind is confusing 
> me :). 
> > I'll try to see if I can combine this loop with another one.
>
> That's one option. Option 2 is to write an interface to the PropertyPool 
> class 
> that allows you to set to zero certain components of all particle 
> properties.
>
> 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/2cd315d9-f961-4dfc-befb-855f64ccb076n%40googlegroups.com.

Re: [deal.II] Clearing a particle properties without getting properties for each particle

[blais...@gmail.com]

The issue is that this code is being called a lot (in our case every 
iteration, so 100k to 10M times) and each iteration is very fast (1k 
iteration is a second or so). Consequently, we've had some severe issue 
when timing in parallel.
If nothing is wrong with the code I guess what I am seeing is just the cost 
of iterating through the particle data structure and valgrind is confusing 
me :). I'll try to see if I can combine this loop with another one.

Thank you very much for the time and the help!



On Sunday, October 18, 2020 at 10:26:35 p.m. UTC-4 Wolfgang Bangerth wrote:

> On 10/17/20 3:50 PM, blais...@gmail.com wrote:
> > Maybe it is callgrind that is playing tricks on me.
> > Here is the code :
> > 
> > for (auto particle = particle_handler.begin();
> > particle != particle_handler.end();
> > ++particle)
> > {
> > // Getting properties of particle as local variable
> > auto particle_properties = particle->get_properties();
> > 
> > // Reinitializing forces and momentums of particles in the system
> > particle_properties[DEM::PropertiesIndex::force_x] = 0;
> > particle_properties[DEM::PropertiesIndex::force_y] = 0;
> > 
> > particle_properties[DEM::PropertiesIndex::M_x] = 0;
> > particle_properties[DEM::PropertiesIndex::M_y] = 0;
> > 
> > if (dim == 3)
> > {
> > particle_properties[DEM::PropertiesIndex::force_z] = 0;
> > particle_properties[DEM::PropertiesIndex::M_z] = 0;
> > }
> > }
> > 
> > With dim a template parameter of the class.
> > The index for the particle properties are part of an enum:
> > enum PropertiesIndex : int
> > {
> > type = 0,
> > dp = 1,
> > rho = 2,
> > v_x = 3,
> > v_y = 4,
> > v_z = 5,
> > acc_x = 6,
> > acc_y = 7,
> > acc_z = 8,
> > force_x = 9,
> > force_y = 10,
> > force_z = 11,
> > omega_x = 12,
> > omega_y = 13,
> > omega_z = 14,
> > mass = 15,
> > mom_inertia = 16,
> > M_x = 17,
> > M_y = 18,
> > M_z = 19,
> > displacement_x = 20,
> > displacement_y = 21,
> > displacement_z = 22,
> > n_properties = 23,
> > };
> > 
> > 
> > I was not sure on what would be the best data structure to identify the 
> data 
> > in the particle properties, hence this type of enum (which I know is 
> maybe not 
> > ideal but...)
> > 
> > Do you have any suggestions? Could it just be the cost of iterating 
> through 
> > the map that callgrinds wrongly affects to the zeroing of the variables?
>
> The code looks ok. I have no idea why that shows up so highly in your 
> profiles, but would check this with a TimerOutput section like we use in 
> other 
> tutorial programs. This also tells you how often the code is actually 
> called. 
> I suspect that valgrind is giving you inaccurate information.
>
> 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/5e415aba-d265-4f43-ac80-7c3773fb8c35n%40googlegroups.com.

Re: [deal.II] Clearing a particle properties without getting properties for each particle

[blais...@gmail.com]

Maybe it is callgrind that is playing tricks on me.
Here is the code :

for (auto particle = particle_handler.begin();
particle != particle_handler.end();
++particle)
{
// Getting properties of particle as local variable
auto particle_properties = particle->get_properties();

// Reinitializing forces and momentums of particles in the system
particle_properties[DEM::PropertiesIndex::force_x] = 0;
particle_properties[DEM::PropertiesIndex::force_y] = 0;

particle_properties[DEM::PropertiesIndex::M_x] = 0;
particle_properties[DEM::PropertiesIndex::M_y] = 0;

if (dim == 3)
{
particle_properties[DEM::PropertiesIndex::force_z] = 0;
particle_properties[DEM::PropertiesIndex::M_z] = 0;
}
}  

With dim a template parameter of the class.
The index for the particle properties are part of an enum:
enum PropertiesIndex : int
{
type = 0,
dp = 1,
rho = 2,
v_x = 3,
v_y = 4,
v_z = 5,
acc_x = 6,
acc_y = 7,
acc_z = 8,
force_x = 9,
force_y = 10,
force_z = 11,
omega_x = 12,
omega_y = 13,
omega_z = 14,
mass = 15,
mom_inertia = 16,
M_x = 17,
M_y = 18,
M_z = 19,
displacement_x = 20,
displacement_y = 21,
displacement_z = 22,
n_properties = 23,
};  


I was not sure on what would be the best data structure to identify the 
data in the particle properties, hence this type of enum (which I know is 
maybe not ideal but...)

Do you have any suggestions? Could it just be the cost of iterating through 
the map that callgrinds wrongly affects to the zeroing of the variables?
On Saturday, October 17, 2020 at 2:30:40 p.m. UTC-4 Wolfgang Bangerth wrote:

>
> > I was wondering if there was a more optimal way to do this? I have 
> profiled it 
> > with callgrind and it seems that getting the properties array view from 
> the 
> > particle can be really expensive.
> > Since what we want to achieve is just to set one of these properties to 
> zero, 
> > I was wondering if there was not a possible optimisation? For example, 
> could 
> > we just get the array view once and assuming its continuity, set all of 
> the 
> > same property to zero?
>
> That seems strange to me. The get_properties() function is in essence a 
> one-liner with a few indirections. Can you show the code in which you set 
> properties to zero?
>
> 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/674e23f3-3a66-48bb-8971-c68280eeb0d5n%40googlegroups.com.

[deal.II] Clearing a particle properties without getting properties for each particle

[blais...@gmail.com]

Dear all,
I hope you are well :).
We are currently facing a weird bottle neck. There are some operation which 
require us to set a particle property to zero and I think we are doing 
something which is not optimal at all. Right now, we loop over the 
particles, then we get the properties array view and set the property to 
zero.

I was wondering if there was a more optimal way to do this? I have profiled 
it with callgrind and it seems that getting the properties array view from 
the particle can be really expensive.
Since what we want to achieve is just to set one of these properties to 
zero, I was wondering if there was not a possible optimisation? For 
example, could we just get the array view once and assuming its continuity, 
set all of the same property to zero?
Sorry if the question seems dumb, I am really less familiar with this type 
of data structure.

Thank you so much!
Bruno


-- 
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/bb428f17-4ce1-4615-b87a-c48a8f11e960n%40googlegroups.com.

[deal.II] Re: Fluid-Structure interaction

[blais...@gmail.com]

Dear Ramiro,
You could also take a look at step-70 by Luca and I. It deplays a very 
prototype-ish fluid-structure interaction framework using immersed 
boundaries. I am sure Luca has progressed a lot on this issue since then. 
You can also look at software derived from Deal.II. Our group develops a 
full Navier-Stokes solver (https://github.com/lethe-cfd/lethe) based on 
deal.II. Extending it to a fluid-structure software could be done 
relatively simply if you want to use a non-monolithic coupling.
Best
Bruno


On Wednesday, October 7, 2020 at 10:29:02 a.m. UTC-4 ramrebol wrote:

> Hi everyone.
>
> I'm looking for a solver to solve a fluid-structure problem, like a heart 
> valve: the valve is an elastic material, and the blood could be considered 
> as an incompressible fluid (evolutionary incompressible Navier--Stokes 
> equations).
>
> In step-46 I see a Fluid-Structure interaction implemented in dealii
>
> https://www.dealii.org/current/doxygen/deal.II/step_46.html
>
> but I'm not sure if it is appropiate to a more realistic problem.
>
> I know that the first thing is to know what is the numerical method that 
> we want implement, but I'm not sure what is the appropiated numerical 
> method to solve this strong coupled problem.
>
> My goal is to implement a model of a valve oppening and close due blood 
> pressure (a cilindrical tube with an elastic obstacle in the middle). Do 
> you think dealii could be an appropiate code to model this? Or is a too big 
> problem?
>
> The other possibility is to use commercial software (COMSOL or ANSIS), but 
> due we don't know what they do to solve the problem, I could prefer to 
> program "my own" solver, for example with dealii.
>
> I suppose there must be many papers proposing algorithms for these types 
> of coupled problems, but I have not found anyone explaining the 
> mathematical aspects behind it. So I am very confused about how to 
> implement this coupled problem.
>
> I don't know if is too much to ask here,  if so, I apologize in advance.
>
> In concrete, my questions are the following:
>
> - what is the numerical algorithm to solve this coupled problem.
> - and, is it possible to solve this with dealii? Or is a too big problem.
>
>
>
>
> -- 
> Ramiro
>

-- 
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/c5a55124-992b-4bec-8135-92bdd60e7c85n%40googlegroups.com.

Re: [deal.II] Issue with unstructured hex mesh

[blais...@gmail.com]

Be careful about SnappyHexMesh. You can use it to make hex-only meshes, but 
it will generate a tesselated mesh (which does not really conform to the 
boundary, it is by all means a voxel mesh).
If you fully use Snappy, it will generate a polyhedral mesh with as many as 
20 faces per element. This is all fine and dandy for FVM (like OpenFOAM), 
but it will not work within deal.II.


On Friday, September 25, 2020 at 4:36:21 p.m. UTC-4 Jean-Paul Pelteret 
wrote:

> Oh, and and just in case you’ve not heard of it before and it might be 
> useful, there’s also this tool that does automated hex meshing:
>
> https://www.openfoam.com/documentation/guides/latest/doc/guide-meshing-snappyhexmesh.html
>
> I’ve never used it though, and I have no idea how you would get the mesh 
> in and out of OpenFOAM, and whether one can prevent the creation of meshes 
> with hanging nodes. Nevertheless, maybe its worth looking into.
>
> Best,
> Jean-Paul
>
> On 25 Sep 2020, at 21:58, Jean-Paul Pelteret  wrote:
>
> Since you have access to Cubit/Trellis, “that patch” is probably not 
> necessary. Cubit uses the Mesquite library for mesh quality improvement, so 
> if you could try to increase the mesh quality that way. Although I’d have 
> to agree with Wolfgang that it might not help too much in this case, but 
> that’s an educated guess.
>
> Best,
> Jean-Paul
>
> On 25 Sep 2020, at 15:04, Wolfgang Bangerth  wrote:
>
> On 9/25/20 4:58 AM, Paras Kumar wrote:
>
> In the quest of alternative solutions, I came across the Mesquite library 
> and was curious to know if that could be helpful to improve the quality of 
> the Delaunay based Hex mesh so as to avoid the issue with stress 
> irregularities.
> It also seems that Mequite's integration within deal.II is under progress[
> https://github.com/dealii/dealii/pull/5971]. \
> Since, I have no prior experience with this library, some guidance wrt the 
> current issue would be of great help.
>
>
> You could try that patch (though I don't know the current status of it -- 
> the issue is that Mesquite is no longer maintained).
>
> But I suspect that it will not help very much. You can understand this in 
> 2d: Even if you have a perfect triangular mesh and then subdivide each 
> triangle into 3 quadrilaterals, you end up with quadrilaterals shows shape 
> can not be improved by moving around nodes. Furthermore, and that seems to 
> be the key issue for theoretical reasons too complicated to discuss here, 
> you really want 2d meshes where at the majority of nodes 4 quadrilaterals 
> come together. But the quadrilateral mesh you get out of subdividing 
> triangles has nodes where either 3, 4, or 6 quadrilaterals come together 
> (corresponding to triangle centers, triangle edge midpoints, and triangle 
> vertices). You end up with much higher errors on these kinds of meshes, and 
> I think that is what you are seeing. Libraries like Mesquite optimize the 
> mesh by moving around nodes, and that has no effect on the valence of nodes.
>
> (I'm sure Mesquite can also do other operations, but they are far more 
> complicated on quad and hex meshes and I don't think the interface enabled 
> that.)
>
> 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+un...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/f4460ec5-52b8-243c-3e34-63cc4171454c%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/7db082e1-e821-4927-bc74-4aa8ccc0db3fn%40googlegroups.com.

Re: [deal.II] Issue with unstructured hex mesh

[blais...@gmail.com]

Dear Paras,
I have faced a lot of similar issues in the past and maybe these 
suggestions can help (or maybe not).

1. Generally visual rendering software (at least paraview) renders data on 
quad/hex meshes using triangular polygons. Consequently, when you look at 
the color map within a square, paraview is actually rendering the square 
using two triangles. Consequently, the color map often appears wrong 
because visually you are not seing the bi-linear interpolation, but some 
sort of "cut in half quad" where each cut is rendered using a linear 
simplex element. Do you think there is another metric you can look at other 
than the visualisation? What you are seeing right now might in fact be an 
artifact of the GPU rendering of your solution.

2. One issue with sub-divided tets into hex is that the added node on the 
triangular face does not match the topology of your geometry. In CFD this 
can introduce very large errors, so I guess it does the same thing for 
solid mechanics. What you can do is generate that mesh in GMSH, then 
"inflate it" to match the manifold of the real geometry you want to 
simulate. This means displacing a few nodes. You can achieve this robustly 
by solving a linear elasticity equation with dirichlet boundary conditoin 
to ensure that your displacement deforms your mesh everywhere. I have found 
this to work very well when the objects are spherical.

3. If the two solutions above don't work, you can try alternative meshing 
software (like cubit). However, they are harder to automatize in a 
GMSH-like fashion.

Feel free to reach out if you need any help!
Best
Bruno

On Wednesday, September 9, 2020 at 2:31:49 p.m. UTC-4 Paras Kumar wrote:

> Dear Prof. Bangerth,
>
> Thank you for your response. 
>
> On Wed, Sep 9, 2020 at 1:08 AM Wolfgang Bangerth  
> wrote:
>
>>
>> Paras,
>>
>> > I am working on homogenization of particulate nano-composites and thus 
>> have to 
>> > solve the finite deformation quasistatics problem on different 
>> > microstructures, such as one shown in the attachment pic-1.png.
>> > 
>> > In order to automate the generation of (2D & 3D) meshes for 
>> microstructures 
>> > comprising of randomly distributed filler particles of arbitrary 
>> radius, we 
>> > employ a self-written python code using GMSH for mesh generation. The 
>> setup 
>> > works well for 2D but for 3D, the resulting mesh (left) culminates in 
>> > irregularities in the stress contour as compared to that obtained with 
>> a 
>> > structured mesh (right) as can be seen from the attachment pic-2.png. 
>> Due to 
>> > the random spatial distribution and arbitrary size of particles, 
>> unstructured 
>> > mesh appeared as the feasible option.
>> > 
>> > In order to verify that the cause of such irregularities is the mesh 
>> and not 
>> > our solver (based on deal.ii), we tested the mesh in Abaqus and similar 
>> > irregularities were observed, cf. pic-3.png. Refining the mesh does not 
>> help 
>> > either.
>>   
>>
> That suggests that you are doing something wrong. I don't know what 
>> exactly 
>> the problem is, and in particular how you assign material properties to 
>> cells, 
>> but we know from theory that the finite element solution must converge to 
>> the 
>> exact solution if you just refine the mesh often enough. If it doesn't 
>> for 
>> you, then something is amiss.
>>
>> I also had this doubt that there was some bug in my code and thus I tried 
> with the Abaqus solver where not much could go wrong except the mesh.
> With regards to material property assignment, it is done by means of 
> *material option within the .inp mesh file (as was also used for the PR 
> https://github.com/dealii/dealii/pull/9466.) and the material IDs appear 
> to be correct when we export the mesh as vtk using deal.II functions and 
> visualize it in Paraview. 
>
> This does not say anything about the *absolute level of accuracy*. I would 
>> not 
>> be surprised if for a mesh like the one you show (in which pretty much 
>> every 
>> hexahedron is poorly shaped), the solution is less than for the 
>> corresponding 
>> tetrahedal mesh. But if you refine it a couple of times, you should get a 
>> more 
>> accurate solution. Is this not the case?
>>
>> We also tried with a refined mesh (resulting in 360K elements as compared 
> to 120K elements for the mesh in pic-2.png), but the irregularities still 
> remain as  can be seen in pic-4.png.Considering that fact that we wish to 
> model multi-particle systems, such large number of elements would render 
> such a mehsing approach computationally infeasible.
>  
>
>>
>> > Has anyone else working with unstructured Hex meshes, observed similar 
>> issues? 
>> > Any clues on how to deal with this issue or on other tools (preferably 
>> open 
>> > source) which one could use for generating better meshes in 3D would be 
>> of 
>> > great help.
>>
>> The quality of meshes matters for the absolute level of error. The hex 
>> meshes 
>> you get by subdividing tets