Re: [deal.II] Adaptive Time Increment Algorithm

[James Gorman]

I apologize that it took so long to respond Jean-Paul, as some things came 
up that kept me away from working on this.

I was going through the code and attempted to integrate it within Step-44 
as appropriate. I appreciate your willingness to share it with me, but I 
have some questions concerning error messages that were made when I tried 
to implement it.

The last portion of the code was commented as ``source''. Am I correct to 
assume you intended for this to be it's own header file to be included in 
the Step-44 introduction?
What was the type of ``first_cycle_refinement''? It appears to only show up 
once in the file you sent.

More errors than the two above occur in the code, but I want to try and 
work through them before asking for additional help...

Bruno, I do appreciate your suggestion, but since Jean-Paul was willing to 
share a portion of his code I'm going to try not to re-invent the wheel.

James

On Thursday, October 15, 2020 at 2:44:01 PM UTC-4 Jean-Paul Pelteret wrote:

> Dear James,
>
>
> I've got some snippets of code that I'll post below to show you how this 
> can be done within the framework of step-44. The basic concept that I 
> implemented is as follows:
>
>
> - The nonlinear solver is called by some function who's job it is to solve 
> for a single timestep. Collectively, they return a status that says what 
> happened within the nonlinear solver. Essentially, the nonlinear solver 
> declares that it took the optimal number of steps to converge (according to 
> its settings), too few steps, too many steps (i.e. we stopped it at some 
> maximum number of iterations), or it diverged completely. This is returned 
> to the main function that performing the loop that steps through time.
>
> - From within that loop, it now decides what to do. If the nonlinear 
> solver converged, but took either the optimal number of steps (say, 3-6) or 
> too few then it accepts the timestep (too few = still converged). If it 
> took too many but still converged, then it will accept the step but the TS 
> size should be adjusted. If the maximum number of iterations are hit 
> without convergence or the solver diverged then we reject the timestep and 
> will have to restart it completely (since this tutorial uses an implicit 
> scheme, linearised about the current timestep, you basically have to reject 
> anything that you've done in that time iterate and start the iterate 
> again). 
>
> - It the nonlinear solver status is then converted to a message for the 
> time stepper. If too few nonlinear iterations were performed, then it tells 
> the time stepper that the timestep size was too small. If the optimal 
> number of steps were taken then it says that the TS size is adequate. If 
> too many steps were taken or the solver diverged then it informs the time 
> stepper that the step size was too large; if no convergence was achieved 
> during that step then it must be performed again after adjustment. (Without 
> employing some sophisticated nonlinear solver, such as the arc length 
> method, then hope is that reducing the timestep size will circumvent the 
> conditions that lead to divergence.) 
>
> - The time stepper would then decide how it adjusts the time step size. A 
> simple scheme would be to halve (or scale by some factor) the timestep size 
> each time its declared to be too large, with some minimum value enforced. 
> Similarly, if the time step size is too large then you could scale the time 
> increment by a constant factor. This would be the most simple approach to 
> try to implement first.
>
>
> I think that those are the most important details. Attached is some code 
> for you to peruse. I extracted it from a project of mine that used step-44 
> as its base, so if it looks like I cropped out anything important then just 
> let me know and I'll try to fill in the gaps. Granted, it's not the easiest 
> to understand but hopefully it, in conjunction with my summary, will give 
> you some idea as to how you could move forward.
>
>
> Best,
>
> Jean-Paul
>
>
> On 14.10.20 02:39, James Gorman wrote:
>
> deal.ii users, 
>
> I'm learning deal.ii with the goal of using it to non-linear solid 
> mechanics problems. In many of these problems (such as Step-44), a time 
> step is used to move a calculation from the initial condition to the final 
> loaded state.
>
> Step-44 uses a uniform time-step, but there are instances where an 
> adaptive time step would be helpful. Using the initial parameter settings 
> in 2-D, I found that a time-step of 0.7 was too large (the residual was on 
> the order of 10^3) for the calculation to converge. 
>
> I modified Step-44 to allow the time increment to increase the time 
> increment when the number of Newton-Raphson iterations for two consecutive 
> increments is small enough. I used global variables to make this happen.
>
> I am, however, at a loss for how to efficiently make it so that Step-44 
> (or any other script) will automatically decrease a 

[deal.II] Re: Post-processing velocities with Trilinos vectors during simulation

[Bruno Turcksin]

Hi,

On Wednesday, November 4, 2020 at 2:34:05 PM UTC-5 acdaig...@gmail.com 
wrote:

> Hi everyone!
>
> I'm working on post-processing velocities with Trilinos solution vectors 
> during the simulation on Lethe. 
> Calculating average velocities and pressures (, ,  and ) works 
> well using Trilinos vectors with no ghost cells and .equ(...) function.
> The calculation of average Reynolds stress (,  and  and 
> average shear stress (), where u' = u - , is quite not easy. 
> It seems that I can't do what I want in parallel without working with loop.
> The problem is that loops seem to take way too much time on Trilinos 
> vectors and the local_range() function doesn't work with BlockVector. (Am I 
> wrong?)
>
True local_range() does not work on a BlockVector but you can get  the 
local_range of each block in the block vector. Just do 
my_block_vector.block(i).local_range()

I have tried some ways to do it. 
>   1. Trying working with Deal.ii vectors : did not work in parallel
>
What does that mean? Did you use the dealii::Vector or the 
dealii::LinearAlgebra::distributed::Vector 
(https://dealii.org/developer/doxygen/deal.II/classLinearAlgebra_1_1distributed_1_1Vector.html)
 
Only the second one supports MPI

  2. Doing summations and/or multiplications of the vectors 
> local_evaluation_point to get u'u', v'v' and w'w' and replacing the fourth 
> element of the evaluation point with a loop for u'v' : too much time.
>   3. Doing loops on the Trilinos vectors : too much time
>
What does that mean it takes too much time? Did you profile the code? 
What's the bottleneck? 

Does anyone can give me an advice to find a way to get one or two vectors 
> with my precious time-averaged Reynolds stress and time-averaged shear 
> stress?
> I did not mention the exact way I'm trying to calculate the average of all 
> of that, but I'm posting my code where I'm trying to do a loop on the 
> solution vector.
> The variables average_velocities, total_time and inv_range_time are 
> calculated in an other function is my class AverageVelocities.
>
> template 
> VectorType
> AverageVelocities::calculate_reynolds_stress(
>   const VectorType &local_evaluation_point,
>   const std::shared_ptr _control,
>   const DofsType &  locally_owned_dofs,
>   const MPI_Comm &  mpi_communicator)
> {
>   if (simulation_control->get_step_number() == 0)
>   {
> // Reinitializing vectors with zeros at t = 0
> sum_reynolds_stress_dt.reinit(locally_owned_dofs,
>   mpi_communicator);
> reynolds_stress.reinit(locally_owned_dofs,
>mpi_communicator);
>   }
>   else if (abs(total_time) < 1e-6 || total_time > 1e-6)
>   {
> VectorType reynolds_stress_dt(locally_owned_dofs,
>   mpi_communicator);
>
> // ***Won't work with BlockVectors
> if constexpr (std::is_same_v TrilinosWrappers::MPI::Vector>)
> {
>   for (unsigned int i = local_evaluation_point.local_range().first;
>i < local_evaluation_point.local_range().second; i++)
>   {
> if ((i + 4) % 4 == 0)
> {
>   // Calculating (u'u')*dt, (v'v')*dt (w'w')*dt and (u'v')*dt
>   reynolds_stress_dt[i] =
> (local_evaluation_point[i] - average_velocities[i]) *
> (local_evaluation_point[i] - average_velocities[i]) * dt;
>   reynolds_stress_dt[i + 1] =
> (local_evaluation_point[i + 1] - average_velocities[i + 1]) *
> (local_evaluation_point[i + 1] - average_velocities[i + 1]) * 
> dt;
>   reynolds_stress_dt[i + 2] =
> (local_evaluation_point[i + 2] - average_velocities[i + 2]) *
> (local_evaluation_point[i + 2] - average_velocities[i + 2]) * 
> dt;
>   reynolds_stress_dt[i + 3] =
> (local_evaluation_point[i] - average_velocities[i]) *
> (local_evaluation_point[i + 1] - average_velocities[i + 1]) * 
> dt;
>
>   // Summation of all reynolds stress during simulation
>   sum_reynolds_stress_dt += reynolds_stress_dt;
>
>   // Calculating time-averaged reynolds stress if output needed
>   if (simulation_control->is_output_iteration())
> reynolds_stress.equ(inv_range_time, sum_reynolds_stress_dt);
> }
>   }
> }
>   }
>   return reynolds_stress;
> }
>
Your for loop is a little bit strange. I would think that the compiler can 
optimize this code but it would be easier for the compiler to optimize the 
following code
 
const unsigned int begin_index = local_evaluation_point.local_range().first; 
// You do this because otherwise the compiler will call local_range() at 
each evaluation of the for loop condition
const unsigned int end_index = local_evaluation_point.local_range().second;
  for (unsigned int i = begin_index;  i < end_index; i += 4)
  {
   // Remove this if ((i + 4) % 4 == 0)
  
  

[deal.II] Re: Some changes in arpack.h (Functionality to compute only eigenvalues)

[Bruno Turcksin]

Animesh,

On Thursday, November 5, 2020 at 1:11:33 PM UTC-5 
animesh...@alumni.iitgn.ac.in wrote:

> However, I have no way of passing it as a parameter to the solver 
> 
>  
> function. I was planning to edit the header file *arpack.h* 
> 
>  
> accordingly which is inside the */usr/local/include/deal.II/lac* to have 
> that functionality. I was actually thinking of passing the flag "rvec" as 
> an argument to the function solve 
> .
>  
> I was wondering if I change the permission of the file to write mode, edit 
> it and save it, would I be able to run my code inside the examples folder. 
> Or do I need to take care of something else while and after editing that 
> headerfile?
>
You should change the source code and reinstall deal.II. I would do what 
you propose only if you cannot compile deal.II on that machine. It might 
work in this particular case but I really advise you against it.

Best,

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/b88a5389-c5a0-458b-97aa-24715d95d9dan%40googlegroups.com.

Re: [deal.II] Use Gmsh to import external grid calculation elasticity problem

[Bruno Turcksin]

Hi,

The function print_mesh_info() ends at line 269. It should end at line 107.

Best,

Bruno

On Wednesday, November 4, 2020 at 9:40:57 PM UTC-5 wjs641...@gmail.com 
wrote:

> Okay, I re-run the program I wrote
> vs told me that ,what that mean?
>
> *2>step-8.obj: error LNK2019: Unresolved external symbol "public: void 
> __cdecl Step8::ElasticProblem<2>::run(void)" 
> (?run@?$ElasticProblem@$01@Step8@@QEAAXXZ)  , The symbol is quoted in the 
> function main 
> 2>D:\dealii-9.2.0\dealii-9.2.0\examples\step-8a\Debug\step-8.exe: fatal 
> error LNK1120: 1 unresolved external command*
> 在2020年11月4日星期三 UTC+8 上午11:09:17 写道：
>
>> On 11/3/20 7:33 PM, Nick Wang wrote: 
>> > 
>> > After I studied and understood the tutorials of step-8 and step-49.  I 
>> tried 
>> > to use  step-49 to import external grids to to calculate the force 
>> condition 
>> > and stress analysis, 
>> > So I modified the statement of step8 grid generation, 
>> > while failed... 
>> > Did I make a mistake or  are there other ways to finish the force 
>> analysis 
>> > from external grids? 
>>
>> Help us understand what the error message is that you get. You already 
>> have it 
>> on your screen, but we would need to download your program, put it 
>> somewhere, 
>> compile it, maybe run it. It would take someone a couple of minutes to do 
>> that 
>> -- time we wouldn't have for answering someone else's problems. 
>>
>> 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/7a2ac5d5-2b40-4b82-a0fe-f7dab8dece32n%40googlegroups.com.

[deal.II] Some changes in arpack.h (Functionality to compute only eigenvalues)

[Animesh Rastogi IIT Gandhinagar]

Dear Dealii community, 

I am using Arpack Solver to compute eigenvalues of my stiffness matrix. To 
speed up the process, I would only like the eigenvalues to be computed and 
not the eigenvectors. There is a flag in arpack.h "rvec" (Link - 
https://www.dealii.org/current/doxygen/deal.II/arpack__solver_8h_source.html#l00796)
 
which essentially takes care of that. 

However, I have no way of passing it as a parameter to the solver 

 
function. I was planning to edit the header file *arpack.h* 
 
accordingly which is inside the */usr/local/include/deal.II/lac* to have 
that functionality. I was actually thinking of passing the flag "rvec" as 
an argument to the function solve 
.
 
I was wondering if I change the permission of the file to write mode, edit 
it and save it, would I be able to run my code inside the examples folder. 
Or do I need to take care of something else while and after editing that 
headerfile?

Also, I guess it would be a good idea to change the arpack.h in the next 
release of dealii so that it can have that functionality. This might help 
many other users. 


Thanks!

Animesh

-- 
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/0b155588-b28a-472a-a452-5cb3bdc37682n%40googlegroups.com.