[deal.II] Newsletter service restored

[Rene Gassmöller]

Dear all,

You may have noticed that the deal.II newsletter was offline for slightly 
more than a month (newsletter #119 
 was sent 
on April 21st). The software problem that caused this outage is fixed, and 
the next regular newsletter should go out tomorrow, with subsequent 
newsletters following the approximately weekly schedule. Because the gap 
covers the release period of deal.II 9.2.0 and a meeting of core developers 
tomorrow's newsletter will contain a new record number of PRs (>400), but 
that should drop down to normal levels in the following weeks. 
Sorry for the inconvenience.

Best,
Rene

-- 
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/a745a247-de4d-451c-b898-20bf6c4147cd%40googlegroups.com.

[deal.II] Re: Particle contact detection

[Rene Gassmöller]

Hi Shahab,

Adding to Luca's reply you probably want to look into the `ParticleHandler` 
class, in particular the `particles_in_cell` function that returns you all 
particles in a given cell 
(https://dealii.org/developer/doxygen/deal.II/classParticles_1_1ParticleHandler.html#acaf1232ffce0746baa64122a5c65822e).
 
By looping through the cell's neighbors you can also find all particles in 
neighbor cells.

Best,
Rene

-- 
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/588b6636-d78b-468c-a94a-57ed3cc73cc5%40googlegroups.com.

[deal.II] Re: Specifying internal "boundary" conditions

[Rene Gassmöller]

Hi Melanie,
we also have a few examples in ASPECT that probably do what you are aiming 
for. E.g. the cookbook prescribed_velocity 
(https://github.com/geodynamics/aspect/blob/master/cookbooks/prescribed_velocity/prescribed_velocity.cc#L295)
 
uses the `add_line` and `set_inhomogeneity` functions to constrain the 
value of the solution to a particular value at a particular location. There 
we still use the deprecated ConstraintMatrix object (that should be 
replaced by the AffineConstraints Bruno mentioned), but the process is more 
or less identical. Let me know if you want to do something similar, but for 
the temperature, I have some code for that elsewhere.

Best,
Rene



On Thursday, September 19, 2019 at 10:55:31 AM UTC-7, Mélanie Gérault wrote:
>
> Dear Bruno,
>
> Thank you, that helps a lot.
>
> Melanie
>
> On Wednesday, September 18, 2019 at 1:58:39 PM UTC-4, Bruno Turcksin wrote:
>>
>> Mélanie,
>>
>> I am not sure I understand exactly what you want to do but often people 
>> who want internal boundary conditions, really just want to impose some 
>> constraints to a few dofs. This can be done using AffineConstraints 
>> . 
>> I am sure that you have seen it in the tutorials where it is used to 
>> constrain hanging nodes and to impose Dirichlet boundary condition. 
>> Basically, you can create one yourself to impose any constraint you want on 
>> any dofs.
>>
>> I hope this help.
>>
>> Bruno
>>
>> On Wednesday, September 18, 2019 at 11:34:12 AM UTC-4, Mélanie Gérault 
>> wrote:
>>>
>>> Hi,
>>>
>>> I am wondering if anyone has ever implemented/used internal boundary 
>>> conditions in deal.II. I need to impose displacements inside of a domain. I 
>>> am assuming that it is feasible with the code, but please let me know if I 
>>> am wrong.
>>>
>>> And in case I need to do it from scratch, I would also appreciate any 
>>> suggestion you may have.
>>>
>>> Thanks a lot!
>>>
>>> Mélanie
>>>
>>

-- 
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/cae559b3-5d70-4467-ad9a-c232517ce1cc%40googlegroups.com.

Re: [deal.II] The type of particle properties

[Rene Gassmöller]

Dear Jinhyun,

It is great to hear that our implementation has been useful for you. You 
are probably aware that we described the implementation in our paper here: 
https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2018GC007508, but 
there is also an earlier version of the article on Arxiv that is a bit more 
verbose about the reasoning behind our choice of property storage scheme: 
https://arxiv.org/pdf/1612.03369.pdf (see Section 2.6). The original 
version of these algorithms have been implemented for the ASPECT project 
(https://github.com/geodynamics/aspect), and I can understand that some of 
the choices might not be optimal for your application. If you want to take 
a look at how we implement our properties (including a tensor valued 
property integrated_strain) you can find some examples here: 
https://github.com/geodynamics/aspect/tree/master/source/particle/property.

Basically, our intention behind the generic property storage type was that 
we do not want to require our users to derive new particle classes from the 
base class for every possible combination of particle properties. As we 
have a large selection of possible properties (you mentioned some), but 
only a subset of properties is actually used in each computation it would 
be wasteful to carry around particles with all properties, and it would be 
cumbersome to write new classes for every different application. May I ask, 
which part of the current approach worries you? The performance overhead 
from copying the properties once per time step should be small compared to 
actually solving equations, and as Wolfgang mentioned you can hide the 
conversion process by having functions like:

Tensor<1,dim> 
get_strain_tensor(const Particle )
{
  ... do the conversion here
}

The main complication when creating child classes for particles would 
probably be the different memory layout. As particles get transferred a lot 
in parallel computation (when they move across domains, during adaptive 
mesh refinement steps, during checkpoints) the ParticleHandler class needs 
to know about their size, and how to serialize them, so if you plan to go 
ahead with a derived particle class this will be the most complicated step. 
This is where the generic particle property shines, because we can simply 
assume we need to store n_properties numbers, instead of figuring out the 
memory requirement for every particle property.

I hope that explains our reasoning behind the design. Let us know if you 
have ideas for how to extend the architecture, or if you have an 
application that absolutely requires an extension of the design.

Best,
Rene




On Saturday, September 14, 2019 at 1:27:57 AM UTC-7, Jinhyun Choo wrote:
>
> Dear Wolfgang,
>
> Thanks for your answer. To be clearer, Yidong and I have been working on 
> the material point method (MPM) which is an offspring of the particle in 
> cell method. We have implemented in using deal.ii as described in our arxiv 
> preprint https://arxiv.org/abs/1905.00671 
> .
>  
> We are now working on parallelizing our implementation of MPM.
>
> As the MPM is developed for solid, a particle in MPM may contain a number 
> of tensors (e.g. stains, stresses, and internal variables) as well as 
> velocities, especially when the constitutive model is complex (typical for 
> geomaterials that we deal with). While it is technically possible to write 
> a function that converts a series of tensors into an array of double, it'd 
> be absolutely better if a particle can carry more general types of 
> properties. (If so, I think it can also be used for general nonlinear FE 
> for solid mechanics.) We'd appreciate it if you could think this as a 
> possible feature in the future!
>
> Best,
> Jinhyun
>
>
> On Saturday, September 14, 2019 at 4:29:30 AM UTC+8, Wolfgang Bangerth 
> wrote:
>>
>> On 9/13/19 1:53 AM, Yidong ZHAO wrote: 
>> > 
>> > I want to store some material properties in particle properties. If 
>> it's 
>> > complicated, I think a better way is to write an interpretation 
>> function. 
>>
>> Yes, do the interpretation function. 
>>
>> I've put my thoughts into some of the documentation. See here: 
>>https://github.com/dealii/dealii/pull/8752/files 
>>
>> 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 

Re: [deal.II] Re: get errors when installing dealii on openSUSE Leap 42.1 by using candi

[Rene Gassmöller]

@Timo: Thanks for the confimation and feedback. 
I needed to do some adjustments to candi to get parmetis to run, but a 
combination of https://github.com/dealii/candi/pull/33 and 
https://github.com/dealii/candi/pull/32 should now be able to automatically 
install deal.II on most Cray machines. @Tuanny: Could you give that a try?

Best,
Rene

Am Mittwoch, 14. Juni 2017 03:44:32 UTC-6 schrieb Timo Heister:
>
> > I am not quite sure what is happening there (I do not have much 
> experience 
> > with PETSc or MUMPS). As far as I can see MUMPS is not a separate 
> package 
> > for deal.II but needs to be installed with PETSc. 
>
> corect. 
>
> > Maybe somebody else knows 
> > which options need to be added to the petsc.package file of candi to 
> make 
> > MUMPS work? 
>
> If you look at petsc.package you can see that you need to have 
> parmetis enabled to get mumps support, which is enabled by default. 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: get errors when installing dealii on openSUSE Leap 42.1 by using candi

[Rene Gassmöller]

I updated the github branch. The file is not longer at the old position, 
instead take a look at: https://github.com/dealii/candi/pull/31

Best
Rene

Am Freitag, 2. Juni 2017 14:55:45 UTC-4 schrieb Rene Gassmöller:
>
> Hi Tuanny,
>
> I happened to install deal.II on a Cray over the last days, and both 
> compiled everything by hand and (afterwards) decided to write a candi 
> script for it. Keep in mind that my instructions are for my specific 
> setting and application, i.e. I compile deal.II with the packages p4est, 
> trilinos, and petsc only, and do not know about other packages. The cluster 
> is also a very specific system (Lonestar 5, of the Texas Advanced Computing 
> Center), but yours is likely at least similar. Anyway, I hope this is of 
> help to you.
>
> The candi platform file with instructions on how to set up the environment 
> is here: 
>
> https://github.com/gassmoeller/candi/blob/lonestar_config/deal.II-toolchain/platforms/lonestar5.platform
>
> You can download it and use it with candi by adding the option 
> --platform=FILENAME where FILENAME contains the full path to this file. On 
> my cluster I had two problems with candi that I needed to change. You can 
> find the modifications I did here: https://github.com/dealii/candi/pull/29 
> and https://github.com/dealii/candi/pull/30. They are not yet part of 
> candi, so you will need to include them manually.
>
> If you decide to compile manually instead let me know, I also have those 
> commands somewhere (not as nicely formatted). The most important point are 
> the loaded modules, environment variables, and compiler options all of 
> which you can see inside the candi script.
>
> Hope that helps a bit,
> Rene
>
>
> Am Donnerstag, 1. Juni 2017 09:53:01 UTC-6 schrieb Tuanny Cajuhi:
>>
>> Thanks a lot, Bruno. 
>> I will keep trying. 
>>
>> On Thu, Jun 1, 2017 at 5:50 PM, Bruno Turcksin <bruno.t...@gmail.com> 
>> wrote:
>>
>>> 2017-06-01 11:37 GMT-04:00 Tuanny Cajuhi <trmc...@gmail.com>:
>>> > You are right, thank you for the explanation. My code uses PetSc with 
>>> MUMPS.
>>> > Just the output is done by Trilinos (the idea of joint_fe). In 
>>> summary, I
>>> > need to add p4est.
>>> Download p4est, untar it, and try something like this:
>>>
>>> ./configure CC=cc CXX=CC F77=ftn --enable-mpi --disable-vtk-binary
>>> --without-blas --prefix=/wherever/you/want
>>>
>>> I may still have some scripts to install deal on cray. I will look for
>>> it tonight
>>>
>>> --
>>> 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/9IMUhsjSGZ8/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> dealii+un...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> *Tuanny Cajuhi*
>> *Computational Sciences in Engineering, **MSc *
>>
>> *+49 176 323 191 85*
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.