[deal.II] Re: Paraview's TemporalInterpolator with adaptive mesh

[Francis Giraldeau]

I tried SolutionTransfer class, but because the DoFHandler is set in the 
constructor and assumed to be refined (or coarsen), we cannot use that 
solution to interpolate to a completely different mesh. Instead, a solution 
is to use VectorTools::interpolate_to_different_mesh() to a mesh that stays 
constant:

Vector interpolated_solution;

interpolated_solution.reinit(dof_handler_export.n_dofs());

VectorTools::interpolate_to_different_mesh(dof_handler, solution, 
dof_handler_export, interpolated_solution);


The result can be interpolated using vtkTemporalInterpolator. I uploaded the 
result at 60fps of step-26 here: https://www.youtube.com/watch?v=1jUUlwOA2fU


Cheers,

-- 
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/1c8d78f5-ca3f-4730-8eae-079286bcad2b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Paraview's TemporalInterpolator with adaptive mesh

[Francis Giraldeau]

To have smooth animation, Paraview has a TemporalInterpolator which renders 
intermediate frames by interpolating the solution between time steps.

However, it works only using a constant mesh. If the mesh changes between 
two time step, then the interpolator fails with this error: 

  Warning: vtkTemporalInterpolator: Interpolation aborted for points 
because the number of tuples/components in each time step are different

One solution could be to export the solution on a fixed mesh, but maybe 
there are other solutions?

Thanks!


  

-- 
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/9aa232af-194d-42bf-816d-78aa3699521a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Installation error on Haswell nodes on Cori at NERSC (failed AVX512 support)

[Stephen DeWitt]

Dear Martin,
Thank you for your response. I deleted everything in my build directory and 
then it worked. I thought that deleting the CMakeCache.txt file and 
CMakeFiles would be enough (in other cases it has been), but evidently it 
wasn't enough here.

Thanks again,
Steve

On Wednesday, July 10, 2019 at 10:04:32 AM UTC-4, Martin Kronbichler wrote:
>
> Dear Steve,
>
> From what I can see the failure is for the expand_instantiations script of 
> deal.II, which is compiled as part of deal.II. It uses slightly different 
> flags as the full install, but assuming that you either passed -xHASWELL or 
> -xCORE-AVX2 to CMAKE_CXX_FLAGS it should not generate that code. Before we 
> look into the flags used for compilation, a basic question: Did you start 
> with a clean build directory without any file left over from a more 
> advanced architecture with AVX512 support?
>
> Best,
> Martin
> On 10.07.19 15:56, Stephen DeWitt wrote:
>
> Hello, 
> I'm trying to install deal.II on the Haswell nodes on Cori at NERSC using 
> the Intel compiler. I'm using deal.II version 9.0, because support for a 
> few of the function calls I make were dropped in v9.1 and I haven't had a 
> chance to modify the sections of the code. In my CMake command, I'm adding 
> either the -xHASWELL or -xCORE-AVX2 flags to get the right level of 
> vectorization for this architecture (AVX). The CMake output is what I 
> expect:
>
> -- 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 - Success
> -- Performing Test DEAL_II_HAVE_AVX512
> -- Performing Test DEAL_II_HAVE_AVX512 - Failed
> -- Performing Test DEAL_II_HAVE_OPENMP_SIMD
> -- Performing Test DEAL_II_HAVE_OPENMP_SIMD - Success
>
> However, when I try to compile I get this error:
>
> [ 32%] Built target obj_umfpack_DL_STORE_release
> [ 34%] Built target obj_amd_global_release
> [ 35%] Built target obj_amd_long_release
> [ 36%] Built target obj_amd_int_release
> [ 37%] Built target obj_muparser_release
> [ 37%] Built target obj_sundials_inst
> Scanning dependencies of target obj_sundials_release
> [ 37%] Building CXX object 
> source/sundials/CMakeFiles/obj_sundials_release.dir/arkode.cc.o
> [ 37%] Building CXX object 
> source/sundials/CMakeFiles/obj_sundials_release.dir/ida.cc.o
> [ 37%] Building CXX object 
> source/sundials/CMakeFiles/obj_sundials_release.dir/copy.cc.o
> [ 38%] Building CXX object 
> source/sundials/CMakeFiles/obj_sundials_release.dir/kinsol.cc.o
> [ 38%] Built target obj_sundials_release
> [ 38%] Generating data_out_dof_data.inst
>
> Please verify that both the operating system and the processor support 
> Intel(R) AVX512F, ADX, AVX512ER, AVX512PF and AVX512CD instructions.
>
> source/numerics/CMakeFiles/obj_numerics_inst.dir/build.make:91: recipe for 
> target 'source/numerics/data_out_dof_data.inst' failed
> make[2]: *** [source/numerics/data_out_dof_data.inst] Error 1
> CMakeFiles/Makefile2:1860: recipe for target 
> 'source/numerics/CMakeFiles/obj_numerics_inst.dir/all' failed
> make[1]: *** [source/numerics/CMakeFiles/obj_numerics_inst.dir/all] Error 2
> Makefile:129: recipe for target 'all' failed
> make: *** [all] Error 2
>
> It seems to me that it is looking for AVX512 support and generating an 
> error when it doesn't find it. But why would it look for AVX512 support if 
> DEAL_II_HAVE_AVX512 failed? I haven't had this issue when installing on 
> other machines that support AVX but not AVX512.
>
> Thanks for any insight you have,
> Steve
> -- 
> 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 dea...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/b36fd46d-2dff-41f4-8762-8ffad6ad4da1%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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/4064831c-921d-4cd0-9fde-a726db3619d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Matrix-Vector-multiplication on deal.II-grid

['Maxi Miller' via deal.II User Group]

It is difficult to write it as a single integral. The operation is similar 
to the split-step fourier method, i.e. transforming the column vector f(r) 
once using
g(rho)=2\pi\int_0^\infty rf(r)J_0(2\pi\rho r)dr,
multiplying it with a vector, and transforming it back using
f(r) = 2\pi\int_0^\infty\rho g(\rho)J_0(2\pi\rho r)d\rho
The operation is for radially symmetric systems, i.e. with z along the 
x-axis, and r along the y-axis. When starting on the left border with f_0, 
i.e. at position z = 0, doing the operation mentioned above gives the 
values for the nodes at z = 1, when enumerating the nodes from 0 to n along 
the z axis, and having equidistant nodes along the z-axis. Those integrals 
can be replaced by a matrix-vector-multiplication, thus making it easier to 
implement numerically.
Does that make sense?

Am Freitag, 12. Juli 2019 18:24:22 UTC+2 schrieb Daniel Arndt:
>
> Maxi,
>
> can you clarify the operator evaluation you want to perform in 
> mathematical terms (maybe as an integral)?
>
> Best,
> Daniel
>

-- 
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/da921bbb-aad9-4ee9-af37-24971c981016%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Matrix-Vector-multiplication on deal.II-grid

[Daniel Arndt]

Maxi,

can you clarify the operator evaluation you want to perform in mathematical 
terms (maybe as an integral)?

Best,
Daniel

-- 
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/435ca58b-e682-45fa-b817-98458471e19d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Matrix-Vector-multiplication on deal.II-grid

['Maxi Miller' via deal.II User Group]

Is it possible to "mis-"use the facilities of deal.II for calculating a NLS 
using the discrete hankel transformation? The idea here was to take an 
evenly refined grid, and calculate the values of each node column based on 
the values of the node column to the left/right times a constant matrix, 
while beginning on the right/left side, and iterating to the other side? 
That would simplify the integration of my equations into my FEM-simulation 
significantly, especially because I can use deal.II-facilities for creating 
and managing the grid.
Thanks!

-- 
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/2b224489-2826-4061-871b-c0ae89fbd070%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Deal.II-Installation on Cluster fails

['Maxi Miller' via deal.II User Group]

Yes, that works, thanks!


Am Donnerstag, 11. Juli 2019 17:01:21 UTC+2 schrieb Daniel Arndt:
>
> Maxi,
>
> Can you just try again with a recent commit?
>
> Best,
> Daniel
>

-- 
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/47daa518-ed5d-4806-b62c-0e1654137c8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] running the "The 'Goal-oriented mesh adaptivity in elastoplasticity problems' code gallery program "

[Muhammad Mashhood]

Similarly the example output log file is attached where the case is being 
simulated in which the gravity is acting for first two loading cases (which 
converge successfully) and from 3rd step the thermal load is started acting 
upon the plate and from this very loading step the Newton solution with 
residual: 115.471 is being accepted (and does not change for future Newton 
iterations) although the residuals for CG solver iterations and the 
difference of two consecutive solutions ( i.e. incremental displacements) 
is going even below 1e-6.  

On Friday, July 12, 2019 at 10:46:59 AM UTC+2, Muhammad Mashhood wrote:
>
> Dear Prof Wolfgang,
>   Hi! I am successful in running the code and 
> it is without a doubt a nice addition to deal.ii code gallery. It 
> reproduces the expected result for 3d Beam case now.
> Since I did not find any thermomechanical coupled example so far in 
> deal.ii therefore I want to contribute in the development and widening the 
> scope of this code by coupling it with heat equation of step-26. 
> For this purpose , taking your lectures as a reference, Initially for 
> testing purpose (i.e. before importing temperature solution from step-26) , 
> I have added the thermal load in the *cell_rhs* as following:
>
>
>
>
>
>
>
>
>
>
>
>
> *  SymmetricTensor<2, dim> thermal_strain_qpoint;  
> /// assigning thermal strain as +ve temperature 
> change in whole body (i.e. all cells expanding equally) 
>   for 
> (unsigned int i=0; i for (unsigned int j=0; j   if (i==j)  
> thermal_strain_qpoint[i][j] = (1-0.3) * 600e-6;//1e-3 ;  // (1-nu) * 
> alpha * del T  else
>   thermal_strain_qpoint[i][j] = 
> 0*1e-3;  // no shear thermal strain in case of homogenous material 
> properties   
> *
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *  for (unsigned int j = 0; j < dofs_per_cell; 
> ++j)cell_matrix(i, j) += 
> (stress_phi_i  * 
> fe_values[displacement].symmetric_gradient(j, 
> q_point)  * 
> fe_values.JxW(q_point));  cell_rhs(i) += 
> (   ( 
> stress_phi_i * 
> incremental_strain_tensor[q_point] )   
> -   ( ( 
> stress_strain_tensor   * 
> fe_values[displacement].symmetric_gradient(i, 
> q_point)) * tmp_strain_tensor_qpoint ) 
>+   ( 
> fe_values[displacement].value(i, 
> q_point) * rhs_values_body_force )
>+   ( 
> fe_values[displacement].symmetric_gradient(i, q_point)
> * stress_strain_tensor * thermal_strain_qpoint   ) // 
> adding the thermal loading force  produced from thermal 
> strains ) * fe_values.JxW(q_point);*
>
> The solid geometry is in the form of rectangular plate (as shown in the 
> attachment where mesh is even finer in the example being tested) with zero 
> displacement (Dirchlet BC) at left edge and so far no mechanical traction 
> load is applied.
> In the result the displacement result is qualitatively as per the 
> expectation i.e. the plate is expanding from other three ends but the 
> System residuals in Newton iterations are of the order of 1e+4 or even more.
> I do not have much experience in under concentration mathematical approach 
> or I might be mistaking in writing the code for thermal loading force term 
> as per deal.ii standards (because the *rhs_values_body_force *term 
> already present in code is even bigger in numerical quantity than the 
> thermal loading term which is added by me but still it lets system converge 
> for small residuals of 1e-5 during solution) therefore I would be grateful 
> to you for any guiding response in my this course of development. Thank 
> you!  
>
>
> On Monday, June 24, 2019 at 10:20:51 AM UTC+2, Muhammad Mashhood wrote:
>>
>> Thank you Prof Wolfgang for your possible support and concern. I will be 
>> waiting for the further support from the author to successfully run it and 
>> to understand the workflow correctly. 
>>
>> On Saturday, June 22, 2019 at 1:51:10 AM UTC+2, Wolfgang Bangerth wrote:
>>>
>>>
>>> Muhammad, 
>>> let me bring the original author of the program (Seyed Shahram Ghorashi) 
>>> into 
>>> the loop as well. 
>>>
>>> > I ran th

Re: [deal.II] running the "The 'Goal-oriented mesh adaptivity in elastoplasticity problems' code gallery program "

[Muhammad Mashhood]

Dear Prof Wolfgang,
  Hi! I am successful in running the code and 
it is without a doubt a nice addition to deal.ii code gallery. It 
reproduces the expected result for 3d Beam case now.
Since I did not find any thermomechanical coupled example so far in deal.ii 
therefore I want to contribute in the development and widening the scope of 
this code by coupling it with heat equation of step-26. 
For this purpose , taking your lectures as a reference, Initially for 
testing purpose (i.e. before importing temperature solution from step-26) , 
I have added the thermal load in the *cell_rhs* as following:












*  SymmetricTensor<2, dim> thermal_strain_qpoint;  
/// assigning thermal strain as +ve temperature 
change in whole body (i.e. all cells expanding equally) 
  for 
(unsigned int i=0; i
> Thank you Prof Wolfgang for your possible support and concern. I will be 
> waiting for the further support from the author to successfully run it and 
> to understand the workflow correctly. 
>
> On Saturday, June 22, 2019 at 1:51:10 AM UTC+2, Wolfgang Bangerth wrote:
>>
>>
>> Muhammad, 
>> let me bring the original author of the program (Seyed Shahram Ghorashi) 
>> into 
>> the loop as well. 
>>
>> > I ran the case of "Cantiliver_beam_3d" and it returned the results 
>> after 
>> > couple of minutes as mentioned in the attachement (where per time step, 
>> > seemingly only one iteration was performed in Newton method and in all 
>> > increamental load steps the result values are zero for both stress and 
>> > displacement). 
>>
>> Good question. I can confirm that that is what the program generates 
>> (though 
>> at least the dual solution is non-zero), but as with all of the code 
>> gallery 
>> programs, we just make them available for others to look at -- we don't 
>> generally know what specifically they are doing, or whether they are 
>> correct. 
>> You will have to ask Seyed Shahram Ghorashi this question. 
>>
>>
>> > Secondly I tried to run the case "Thick_tube_internal_pressure" which 
>> first 
>> > popped up the dialog message of : 
>>  > [...] 
>> > Where as per my understanding of template based nature of deall.ii and 
>> also 
>> > this case is 2d so if I change the *dim = 2* from originally *dim = 3* 
>> in main 
>> > function of elastoplastic.cc 
>>
>> Yes, this is the correct solution. 
>>
>>
>> > then the following error comes during compilation : 
>> > [...] 
>>
>> Yes, I can confirm this as well. I will admit that I don't think this 
>> ever worked. 
>>
>> In the end, this is really the limitation of the code gallery. We see it 
>> as a 
>> way for our users to share codes that may be of use to others in the 
>> community, but we do not endorse them or verify the quality of these 
>> codes. 
>> It's also quite possible that they *used* to work correctly with older 
>> deal.II 
>> versions, but don't any more -- I could imagine that being the situation 
>> with 
>> the first problem above. 
>>
>> Let's hope that Seyed has something to add that help you! 
>>
>> Best 
>>   WB 
>>
>> -- 
>>  
>> 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/eeefe5f2-0947-4e02-8f12-37d6dbe8f221%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


solution-0001-.eps
Description: PostScript document