Re: [deal.II] Newsletter service restored

2020-05-28 Thread Wolfgang Bangerth

On 5/28/20 5:53 PM, Rene Gassmöller wrote:
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.


Oh to zero -- I think we all need a break, as you will see once you see the 
impressive list! :-)


Cheers
 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/d913af88-7bda-0c66-9b37-254b9f430abf%40colostate.edu.


[deal.II] Newsletter service restored

2020-05-28 Thread 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.


Re: [deal.II] Using different random seed when distorting a triangulation

2020-05-28 Thread David F
Yes, it seems indeed easy. I'll try to learn how to send it through the 
official channel in github.

On Tuesday, 26 May 2020 05:40:57 UTC+2, Wolfgang Bangerth wrote:
>
> On 5/25/20 9:20 PM, David F wrote: 
> > 
> > I would like to apply many random distortions to a triangulation. 
> However, the 
> > function GridTools::distort_random seems to produce always the same 
> > distortion. Is there a way to use different seeds in order to generate 
> always 
> > different distortions? It seems that it's not possible through the 
> interface 
> > of GridTools::distort_random but I wonder if there is another way to do 
> it, 
> > since this seems to me a very basic feature for the users of this 
> function. 
>
> Interesting question! 
>
> The function doesn't currently allow that, it uses the same sequence of 
> random 
> numbers every time -- by design: This way, if you run your program twice 
> in a 
> row, it'll produce the same result. 
>
> But it wouldn't be very difficult to change that. The function is here: 
>
> https://github.com/dealii/dealii/blob/master/source/grid/grid_tools.cc#L1013-L1244
>  
> The random number generator is initialized in line 1099. It wouldn't be 
> very 
> difficult to add an argument to the function that acts as a random seed 
> and is 
> used in that line to seed the boost::random::mt19937 generator. Want to 
> give 
> this a try and implement such a change? We'd of course be very happy to 
> take a 
> patch! 
>
> 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/1d6b5b3f-03b4-4de0-b186-f7ca9612f2a2%40googlegroups.com.


Re: [deal.II] table.h errors

2020-05-28 Thread Wolfgang Bangerth

On 5/26/20 8:36 PM, Jammi Ashok wrote:

Actually I cloned deal-ii from github. Day before yesterday.


Jammi -- so does it work in the cloned repository? As I mentioned, we 
regularly compile with MS Visual Studio...


Best
 WB

--

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/964a38e2-ea09-5802-5a53-5d91daf7a51c%40colostate.edu.


Re: [deal.II] problem measure() for quads

2020-05-28 Thread Wolfgang Bangerth

On 5/28/20 3:08 AM, Andreas Kyritsakis wrote:


I have a problem with using the measure() function for quads in 3D. I am 
currently using version 9.1.1 and the function seems to check whether the face 
is planar and if not, it returns nan. The problem is that the tolerance for 
considering it planar is extremely low (1.e-24), which causes problems. If for 
example the mesh is read in from a standard .msh file, written by the GridOut 
class, we cannot expect to get such a precision in the vertices. I saw that in 
the 9.2 version this is partially fixed by handling the non-planar case by 
numerical intergration, but the tolerance has remained the same extremely low, 
which might result in unnecessary computational effort.


I wonder whether the tolerance can be increased to something more reasonable 
(e.g. 1.e-10) or there is something I am missing that suggests such a low 
tolerance.


It's a good question. I checked that the expression in question is 
dimensionless and scaled correctly so that the mesh size h does not appear in 
the size of the expression. I think it would be quite ok if you changed the 
tolerance to 1e-10.


Want to propose a patch for this?

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/71bb3592-4178-9b7a-0ab5-580c8a49f090%40colostate.edu.


Re: [deal.II] vertex and dofcells

2020-05-28 Thread Alberto Salvadori
Thank you, Jean Paul. Exhaustive, as usual.


*Alberto Salvadori* Dipartimento di Ingegneria Meccanica e Industriale
(DIMI)
 Universita` di Brescia, via Branze 43, 25123 Brescia
 Italy
 tel 030 3715426

e-mail:
 alberto.salvad...@unibs.it
web-page:
 http://m4lab.unibs.it/faculty.html



On Tue, May 26, 2020 at 6:42 PM Jean-Paul Pelteret 
wrote:

> Dear Alberto,
>
> Quick answer: There’s a entry in the FAQ that may answer your question:
>
> https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#how-do-i-get-the-degree-of-freedom-indices-at-vertices
>
> As mentioned at the bottom of that entry, is a small point on how to go
> from DoFs -> vertices using DoFTools::map_dofs_to_support_points()
> 
> .
>
> Does this help you?
> Best,
> Jean-Paul
>
> On 26 May 2020, at 18:35, Alberto Salvadori 
> wrote:
>
> Dear community,
>
> this looks a simple question but I just cannot find a simple answer, I
> apologize.
>
> The code I aim at writing is similar to:
>
> *unsigned* vv = 0 ;
>
>
> *for* (*unsigned* *int* ii=0; ii
> {
>
>   *const* *unsigned* *int* ii_group = manifold_fe
> .system_to_base_index(ii).first.first;
>
>
>   *if* ( ii_group == manifold_dofs.cS_dof )
>
>   {
>
> Point this_node = cell->vertex(vv) ;
>
>
> [ ... omitted code ... ]
>
>
> cell_matrix( ii,ii ) = 1 ;
>
> cell_rhs( ii ) = some_function_of( this_node );
>
>
> ...
>
> ++vv;
>
>   }
>
>  }
>
>
> In a nutshell, I want to retrieve information that I stored at each node
> of the cell, while looping on the dofcells.
> I am not sure if the order of the dofs and of the vertex coincide, suspect
> they do not.
> Can you please address me to a function that connects the dofcells to the
> associated vertex,or suggest a better approach?
>
> Thank you so much
>
> Alberto
>
>
> Informativa sulla Privacy: http://www.unibs.it/node/8155
>
> --
> 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/3a275ee6-9416-4547-8a81-188c29579e2a%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/F28279CC-8C0A-4CFC-84AC-4D97BE725C2E%40gmail.com
> 
> .
>

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 


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


[deal.II] problem measure() for quads

2020-05-28 Thread Andreas Kyritsakis
Hi,

I have a problem with using the measure() function for quads in 3D. I am 
currently using version 9.1.1 and the function seems to check whether the 
face is planar and if not, it returns nan. The problem is that the 
tolerance for considering it planar is extremely low (1.e-24), which causes 
problems. If for example the mesh is read in from a standard .msh file, 
written by the GridOut class, we cannot expect to get such a precision in 
the vertices. I saw that in the 9.2 version this is partially fixed by 
handling the non-planar case by numerical intergration, but the tolerance 
has remained the same extremely low, which might result in unnecessary 
computational effort. 

I wonder whether the tolerance can be increased to something more 
reasonable (e.g. 1.e-10) or there is something I am missing that suggests 
such a low tolerance.

Best regards,
Andreas Kyritsakis

-- 
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/b52ebd60-f264-4512-92f5-144f1e3d5f5a%40googlegroups.com.