Re: [deal.II] Tips and tricks for functional tests on chaotic systems
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&feature=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.
Re: [deal.II] Tips and tricks for functional tests on chaotic systems
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: bange...@colostate.edu www: http://www.math.colostate.edu/~bangerth/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/aae0abac-0e65-5f49-1127-ee3ba8544a2f%40colostate.edu.
[deal.II] Tips and tricks for functional tests on chaotic systems
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.
Re: [deal.II] Re: Parallel distributed hp solution transfer with FE_nothing
The FiniteElementDomination logic in the codim=0 case would indeed make up a cheap a priori check in this context. In case a FE_Nothing has been configured to dominate, the solution should be continuous on the interface if I understood correctly, i.e., zero on the face. I will write a few tests to see if this is actually automatically the case in user applications. If so, this check for domination will help other users to avoid this pitfall :) Marc On Monday, December 28, 2020 at 4:13:40 PM UTC-7 Wolfgang Bangerth wrote: > > > The problem here is that the solution is not continuous across the face > of a > > FE_Q and a FE_Nothing element. If a FE_Nothing is turned into a FE_Q > element, > > the solution is suddenly expected to be continuous, and we have no rule > in > > deal.II yet how to continue in the situation. In my opinion, we should > throw > > an assertion in this case. > > Denis actually thought of that already a while back. It wasn't well > documented, but see here now: > https://github.com/dealii/dealii/pull/11430 > > Does that also address what you wanted to do in your patch? > > 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/5c35ba6e-6deb-42a2-8ef1-aa45bba097dan%40googlegroups.com.
Re: [deal.II] Re: Parallel distributed hp solution transfer with FE_nothing
The problem here is that the solution is not continuous across the face of a FE_Q and a FE_Nothing element. If a FE_Nothing is turned into a FE_Q element, the solution is suddenly expected to be continuous, and we have no rule in deal.II yet how to continue in the situation. In my opinion, we should throw an assertion in this case. Denis actually thought of that already a while back. It wasn't well documented, but see here now: https://github.com/dealii/dealii/pull/11430 Does that also address what you wanted to do in your patch? Best W. -- Wolfgang Bangerth email: bange...@colostate.edu www: http://www.math.colostate.edu/~bangerth/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/c6f6b846-9955-a8a6-74c5-785faefa5efc%40colostate.edu.
Re: [deal.II] Re: Parallel distributed hp solution transfer with FE_nothing
Hi Wolfgang, your explanation makes indeed more sense in the context of piecewise polynomials :) The problem here is that the solution is not continuous across the face of a FE_Q and a FE_Nothing element. If a FE_Nothing is turned into a FE_Q element, the solution is suddenly expected to be continuous, and we have no rule in deal.II yet how to continue in the situation. In my opinion, we should throw an assertion in this case. I have a patch for the p::d case in mind what will warn users about this: we should reinit the solution vector with NaNs and than only overwrite the entries once. I don't know if we have such a test for the general SolutionTransfer class. I will check that. Marc On Monday, December 28, 2020 at 1:39:33 PM UTC-7 Wolfgang Bangerth wrote: > On 12/27/20 8:48 PM, Marc Fehling wrote: > > > > 2) I did not know you were trying to interpolate a FENothing element > into a > > FEQ element. This should not be possible, as you can not interpolate > > information from simply 'nothing', and some assertion should be > triggered > > while trying to do so. The other way round should be possible, i.e., > > interpolation from FEQ to FENothing, since you will simply 'forget' what > has > > been on the old cell. > > In hindsight, FE_Nothing was maybe a poorly named class. It should really > have > been FE_Zero: A finite element space that contains only a single function > -- > the zero function. Because it only contains one function, it requires no > degrees of freedom. > > So interpolation from FE_Nothing to FE_Q is well defined if you take this > point of view, and projection from any finite element space to FE_Nothing > is also. > > 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/9e381e90-abeb-402a-96c8-3d43c33c8ff7n%40googlegroups.com.
Re: [deal.II] Re: Parallel distributed hp solution transfer with FE_nothing
On 12/27/20 8:48 PM, Marc Fehling wrote: 2) I did not know you were trying to interpolate a FENothing element into a FEQ element. This should not be possible, as you can not interpolate information from simply 'nothing', and some assertion should be triggered while trying to do so. The other way round should be possible, i.e., interpolation from FEQ to FENothing, since you will simply 'forget' what has been on the old cell. In hindsight, FE_Nothing was maybe a poorly named class. It should really have been FE_Zero: A finite element space that contains only a single function -- the zero function. Because it only contains one function, it requires no degrees of freedom. So interpolation from FE_Nothing to FE_Q is well defined if you take this point of view, and projection from any finite element space to FE_Nothing is also. Best Wolfgang -- Wolfgang Bangerth email: bange...@colostate.edu www: http://www.math.colostate.edu/~bangerth/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/72c3545b-70bf-afa8-2b8c-bcb121805bac%40colostate.edu.
Re: [deal.II] Using Dealii to developing aa finite element software on Windows
On 12/26/20 10:08 PM, amir kiani wrote: By reading tutorials on the website of Deal.ii, I realized that using Deal.ii directly on windows is experimentally supported. That may no longer be an accurate description. deal.II 9.2 is used in a number of industrial applications that run on Windows. It definitely works on Windows. Best W. -- Wolfgang Bangerth email: bange...@colostate.edu www: http://www.math.colostate.edu/~bangerth/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/75e252ef-0e7e-c5dc-6703-57cc514ee84c%40colostate.edu.
Re: [deal.II] Re: Mean Value Constraints
On 12/26/20 3:06 AM, Konrad Simon wrote: What one can also do is just constrain one DoF to a specific value (this would also remove rigid motion in elasticity). But think about your solution variable: If it is in the Sobolev space H^1 then point evaluations may not be defined for dimension larger than 2. Similarly if, for example, the pressure in a mechanical or fluid problem is often just in L^2. Point evaluations do not make sense there at all. Right, this is the correct approach: Constrain a single degree of freedom to zero (or any other value you choose) and solve the problem. Then you can subtract the mean value of the solution *after* solving the linear system. (See VectorTools::subtract_mean_value and VectorTools::compute_mean_value.) If you're uncomfortable with the ill-posedness of taking a point value, you can also take the mean value along a small segment of the boundary (step-1) or a small part of the domain. But in practice, this is not necessary and Konrad's solution is what everyone seems to be doing. Best W. -- Wolfgang Bangerth email: bange...@colostate.edu www: http://www.math.colostate.edu/~bangerth/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/83478e87-c896-b40a-f51e-42f76ade2c4b%40colostate.edu.
Re: [deal.II] Using Dealii to developing aa finite element software on Windows
Hi Amir, deal.II 9.1 requires c++11 deal.II 9.2 requires c++11 deal.II 9.3 will require c++14 Your only choice would be to use an older version of deal.II but I would strongly suggest updating your compilers instead. On Sun, Dec 27, 2020 at 12:09 AM amir kiani wrote: > > Hello. > Recently I started to learn finite element programming. > By surfing the net, I came to C++ and Deal.ii. > One of my concerns in using Deal.ii and C++ is about any possible future > limitations. > By reading tutorials on the website of Deal.ii, I realized that using Deal.ii > directly on windows is experimentally supported. > Now my main question: > As presented on the Deal.ii Website, If I build Deal.ii via each approach > (and in any operating system like Linux), Can I use classes and libraries of > Deal.ii in other C++ programs? Consider I want to use Deal.ii features in > C++03 with Visual Studio 2008 on Windows 7. > Because I am working on developing an existing software, I am restricted to > use this standard of C++ and this version of Visual Studio. > I appreciate all answers in advance > > -- > 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/a4df4788-b1c4-44e6-97c1-b06b6912554dn%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/CAMRj59H%2B8vXqn0WJb4aAQ_MyfWkfAz7CogB9kp55pycfe6vfgg%40mail.gmail.com.
[deal.II] MGConstrainedDoFs::initialize with no constrains
Dear all, I'm considering a multigrid method for the Stokes problem. I need to have an approximation of Schur complement at each level that is represented by a matrix-free operator. The problem is that in case of adaptive mesh refinement MGConstrainedDoFs assumes zero boundary condition at refinement edges. In my case that behaviour is unwanted. I have looked through the implementation of MGConstrainedDoFs and it looks like it will require changing initialize() function by adding 1 additional parameter: MGConstrainedDoFs::initialize ( const DoFHandler< dim, spacedim > & dof, const MGLevelObject< IndexSet > & level_relevant_dofs = MGLevelObject() const bool& set_zero_constrain_at_refinement_edge=true) And adding if in line 331: if(set_zero_constrain_at_refinement_edge) MGTools::extract_inner_interface_dofs(dof, refinement_edge_indices); The other option to implement my MG preconditioner is to rewrite MGConstrainedDoFs together with all MG classes that rely on it. Best, Michał -- 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/8c43a6e1-875e-4150-b15d-14b56ab438dan%40googlegroups.com.
