Re: [deal.II] [deal.ii]mesh import problem

[Wolfgang Bangerth]

Chen,


I want to import the mesh file exported by gmsh.
[...]

*Could anyone let me known how to import mesh ?*


First, our apologies for not replying to this issue earlier. These 
interactions with other programs are really thorny :-(


I've taken a look at your input VTK file. The first issue is that our reader 
in GridIn expects (maybe unreasonably so) that cells are listed before lines 
in the CELLS section. This is relatively easy to fix by swapping the lines and 
cells in the CELLS and CELL_TYPES section of your input file.


But the more relevant part is that one then runs into the following error:
...
An error occurred in line <2690> of file 
 in function
static void 
dealii::internal::TriangulationImplementation::Implementation::create_triangulation(const 
std::vector >&, const std::vector >&, 
const dealii::SubCellData&, dealii::Triangulation<2, spacedim>&) [with int 
spacedim = 2]

The violated condition was:
line->boundary_id() != numbers::internal_face_boundary_id
Additional information:
The input data for creating a triangulation contained information about a 
line with indices 1 and 49 that is described to have boundary indicator 0. 
However, this is an internal line not located on the boundary. You cannot 
assign a boundary indicator to it.


If this happened at a place where you call 
Triangulation::create_triangulation() yourself, you need to check the 
SubCellData object you pass to this function.


If this happened in a place where you are reading a mesh from a file, then you 
need to investigate why such a line ended up in the input file. A typical case 
is a geometry that consisted of multiple parts and for which the mesh 
generator program assumes that the interface between two parts is a boundary 
when that isn't supposed to be the case, or where the mesh generator simply 
assigns 'geometry indicators' to lines at the perimeter of a part that are not 
supposed to be interpreted as 'boundary indicators'.

...

The description of the error message already suggests the problem. You need to 
somehow convince gmsh to not output information about line segments at all.


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/2b99a9fc-aaac-13fd-6da0-01dbfd212816%40colostate.edu.

Re: [deal.II] Output of Gauss point stress tensor

[Wolfgang Bangerth]

On 7/16/20 9:15 AM, Muhammad Mashhood wrote:
So far it would be enough if I have the Gauss point values only at the points 
rather than having complete field. I like to access these point values of 
stress and strain tensors in .vtk file or .pvtu file through ParaView (same as 
I am accessing the results currently).
I would be grateful if you or any other user has experience in this regard or 
know about relevant deal.ii tutorial dealing with same feature.


deal.II has functionality to output data on individual points if that data is 
associated with particles. I don't know how much work you want to invest in 
getting this to work for you, but here are two options:


* Easy: Create a ParticleHandler object, loop over all of your quadrature 
points, and for each quadrature point you create a particle. You can then 
associate "properties" with each particle, and use Particles::DataOut to 
output these properties in the same way as you would use DataOut for field 
data. You can probably figure out how this works by looking at the draft 
step-19 tutorial program:

  https://github.com/dealii/dealii/pull/10301

* More work, but more elegant: You could write a class, let's say 
QuadraturePointData::DataOut or something similar, to which you could describe 
the information of location + values without the detour of particles. I'm sure 
we'd be happy to walk you through the process of doing so if you wanted to go 
for that, and it would be a very nice addition to deal.II if you wanted to get 
it merged.


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/852a3e77-e242-4f9e-4182-2635e418b6bd%40colostate.edu.

Re: [deal.II] Particles and field interpolation error

[luca.heltai]

Ciao Franco, 

ParticleHandler was built with the intention of “losing” particles whenever 
they fall out of the domain. This is the default behaviour of the 
ParticleHandler, and unless you store a pointer to an existing particle 
somewhere, you should not be in trouble. 

If you iterate over the particles using the ParticleHandler, you should be 
safe. The Utilities::interpolate_on_field cannot know how many particles are 
actually there, so it asks the ParticleHandler for the 
next_available_particle_index(), which should not change, even if you drop some 
particles.

The way the interpolator works, is by looping *through* the ParticleHandler 
(again, on the safe side), and deciding what to store where based on the 
current particle id. Unless you renumber and reset all particle ids between the 
removal and the interpolation, this will remain consistent.

Luca.

> On 16 Jul 2020, at 13:47, franco.m...@gmail.com  
> wrote:
> 
> Thanks, Luca.
> 
> I have read the documentation, that's why I was skeptic of my own code: I 
> still think I am doing it wrong.
> 
> As far as I understand from the documentation, particles should be removed 
> from the handler after updating the cache, and thus the interpolated field 
> should not contain the old removed one. Unfortunately I don't see any mention 
> of "removal" in Particles::Utilities, but I could overlooking something here.
> 
> Another question relative to the removal part is more of a worry. If I remove 
> a particle, will any iterator be invalidated? If so, and say I need to remove 
> a lot of particles, what is the best way to do this without too much 
> overhead? As I understand, I have to remove (just one?) a particle and call a 
> cache update at the end of the removal process.
> 
> Thanks!
> Franco
> On Wednesday, July 15, 2020 at 7:47:58 PM UTC+2 luca@gmail.com wrote:
> Franco,
> 
> The interpolated field says that the field value is zero (on the line above 
> your arrow). This is how it is documented: if a particle is removed, its 
> interpolated value is left unchanged in the target vector. Zero in your case. 
> 
> Luca
> 
>> Il giorno 15 lug 2020, alle ore 18:18, Franco Milicchio 
>>  ha scritto:
>> 
>> 
>> Dear all,
>> 
>> I am playing with 9.2 and particles, but I've encountered a weird problem. 
>> If I remove a particle, the interpolated field on particle locations yields 
>> a wrong answer.
>> 
>> My code does (now) everything by hand:
>> 
>>   // Here be drangons...
>> 
>>   Point<2> p_0(0.1,0.5);
>>   auto ref_cell_0 = GridTools::find_active_cell_around_point(dof_handler, 
>> p_0);
>>   Point<2> ref_p_0 = 
>> StaticMappingQ1<2>::mapping.transform_real_to_unit_cell(ref_cell_0, p_0);
>> 
>>   Point<2> p_1(0.5,0.5);
>>   auto ref_cell_1 = GridTools::find_active_cell_around_point(dof_handler, 
>> p_1);
>>   Point<2> ref_p_1 = 
>> StaticMappingQ1<2>::mapping.transform_real_to_unit_cell(ref_cell_1, p_1);
>> 
>>   Point<2> p_2(0.9,0.5);
>>   auto ref_cell_2 = GridTools::find_active_cell_around_point(dof_handler, 
>> p_2);
>>   Point<2> ref_p_2 = 
>> StaticMappingQ1<2>::mapping.transform_real_to_unit_cell(ref_cell_2, p_2);
>> 
>>   particle_handler.insert_particle(Particles::Particle<2>(p_0, ref_p_0, 0), 
>> ref_cell_0);
>>   particle_handler.insert_particle(Particles::Particle<2>(p_1, ref_p_1, 1), 
>> ref_cell_1);
>>   particle_handler.insert_particle(Particles::Particle<2>(p_2, ref_p_2, 2), 
>> ref_cell_2);
>> 
>>   particle_handler.update_cached_numbers();
>> 
>>   std::cout << "Printing particle id, location and reference location" << 
>> std::endl;
>>   for(auto :particle_handler)
>>   {
>> std::cout << "id: " << p.get_id() << "  loc: " << p.get_location() << "  
>> ref_loc: " << p.get_reference_location() << std::endl;
>>   }
>> 
>>   field_on_particles.reinit(particle_handler.n_global_particles());
>>   Particles::Utilities::interpolate_field_on_particles(dof_handler, 
>> particle_handler, field, field_on_particles);
>> 
>>   std::cout << "Printing field value on particle location" << std::endl;
>>   for(int pp = 0; pp< particle_handler.n_global_particles(); pp++)
>>   {
>>   std::cout << "fluid id: " << pp << " value: " << 
>> field_on_particles[pp] << std::endl;
>>   }
>> 
>>   // 
>>   // NOW REMOVE A PARTICLE...
>>   // 
>> 
>>   for(auto itr=particle_handler.begin(); itr != particle_handler.end(); 
>> itr++)
>>   {
>> if(itr->get_id()==1) particle_handler.remove_particle(itr);
>>   }
>> 
>>   particle_handler.update_cached_numbers();
>> 
>> 
>>   // ***
>>   // ...AND VALUES ARE WRONG
>>   // ***
>> 
>>   std::cout << "Printing particle id, location and reference location after 
>> removing particle" << std::endl;
>> 
>>   for(auto itr_2=particle_handler.begin(); itr_2 != particle_handler.end(); 
>> itr_2++)
>>   {
>> std::cout << "id: " << itr_2->get_id() << "  loc: " << 
>> itr_2->get_location() << "  ref_loc: " << 

Re: [deal.II] New docker image for deal.II 9.2.0

[luca.heltai]

We should all thank Matthias. He’s the one responsible for the "apt-get install 
deal.ii-dev” magic which is happening here…

:)

Luca.

> On 16 Jul 2020, at 19:22, Bruno Blais  wrote:
> 
> Awesome!
> Thank you so much for taking the time to prepare these images Luca. They are 
> amazingly helpful for those using Travis_CI for their deal.II derived codes 
> :).
> 
> 
> On Wednesday, 15 July 2020 05:04:31 UTC-4, luca.heltai wrote:
> Dear all, 
> 
> I’d like to inform you that we now have also docker images with deal.II 
> 9.2.0, based on ubuntu bionic (18.04.1), and based on ubuntu focal (20.04.1). 
> 
> You can find them with 
> 
> docker pull dealii/dealii:v9.2.0-bionic 
> docker pull dealii/dealii:v9.2.0-focal  (dealii/dealii:latest) 
> 
> Best, 
> Luca. 
> 
> 
> -- 
> 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/77ba1dd9-9623-4392-9398-f33631a0328do%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/280CDDC2-2368-4AF9-83A3-5CE667EC6378%40gmail.com.

[deal.II] Re: New docker image for deal.II 9.2.0

[Bruno Blais]

Awesome!
Thank you so much for taking the time to prepare these images Luca. They 
are amazingly helpful for those using Travis_CI for their deal.II derived 
codes :).


On Wednesday, 15 July 2020 05:04:31 UTC-4, luca.heltai wrote:
>
> Dear all, 
>
> I’d like to inform you that we now have also docker images with deal.II 
> 9.2.0, based on ubuntu bionic (18.04.1), and based on ubuntu focal 
> (20.04.1). 
>
> You can find them with 
>
> docker pull dealii/dealii:v9.2.0-bionic 
> docker pull dealii/dealii:v9.2.0-focal  (dealii/dealii:latest) 
>
> Best, 
> Luca. 
>
>

-- 
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/77ba1dd9-9623-4392-9398-f33631a0328do%40googlegroups.com.

[deal.II] Re: New deal.II 9.2.0 package for MAC

[Ester Comellas]

Hi Luca,

In case it's useful, I just updated to this version using the link 
provided. Although deal.ii runs for me (both in release and debug modes), I 
always get a warning message similar to the one that Alberto Salvadori 
reported a month ago here 
. I'm 
using macOS 10.15.6 (19G73) and XCode 11.5 (11E608c).

I typed "module load dealii" before compiling the code. My .profile file 
has the following line:
export PATH="/Applications/CMake.app/Contents/bin:$PATH"

I attach a text file with the output I get on my Terminal. Like Alberto 
wrote in his post, it seems like it can't find 
zlib-1.2.11-rqiqrujgg5aemhk7eqjk3asbaukff. 
When I check the path, I see there's the directory 
zlib-1.2.11-rqiqrujgg5aemhk7eqjk3asbaukff37x instead. 
However, when I run my code it seems to do fine. I have no clue what zlib 
does, maybe I'm not using it? I also tried step-17 and step-44 and they run 
smoothly.

Not sure this message is relevant, but I'm posting just in case it helps 
other users, or the developers to improve future releases for macOS.

Best,
Ester


El dimecres, 24 juny de 2020 18:31:44 UTC+2, luca.heltai va escriure:
>
> Dear All, 
>
> there has been an issue with the deal.II Package which I hope I was able 
> to resolve. 
>
> The new mac package is in the same place of the old one 
>
> https://github.com/dealii/dealii/releases/download/v9.2.0/dealii-9.2.0.dmg 
>
> Would anyone with a mac try it out and tell me if they can run it? 
>
> Luca. 
>
>

-- 
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/239da517-18b5-4c31-8788-0690bb13ee0bo%40googlegroups.com.


Comellas_dealii-9.2.0_terminal-ouput.rtf
Description: RTF file