>39 SNES Function norm 3.758101652998e-08
> 0 KSP preconditioned resid norm 1.931834799209e-02 true resid norm
> 3.758101652998e-08 ||r(i)||/||b|| 1.e+00
> 1 KSP preconditioned resid norm 5.958979968059e-16 true resid norm
> 2.588244438237e-18 ||r(i)||/||b||
Let me suggest that you grab a hold of Simo and Hughes, Computational
Inelasticity, Springer-Verlag (1998). It explains a lot about how to
set up this problem -- in particular Chapter 1 gives a comprehensive
one-dimensional tutorial on everything you need to know.
On 7/5/17 9:39 AM,
On Wed, Jul 5, 2017 at 9:39 AM, Maximilian Hartig
wrote:
> I do not clearly understand the discrimination between local and global
> plasticity. I do have areas where I expect the behaviour to be elastic and
> other areas where I expect elasto-plastic behaviour.
>
I do not clearly understand the discrimination between local and global
plasticity. I do have areas where I expect the behaviour to be elastic and
other areas where I expect elasto-plastic behaviour.
Inertia effects are of importance and hence I need second order temporal
derivatives of my
Plasticity should not cause any major difficulties with your global
iterations. Your residuals look your load steps are elastic all the
way until it fails. Are you sure that your applied boundary conditions
have a unique solutions? In particular, are you applying forces to a
perfect
The solver goes on for some timesteps, then it gets hung up in step 10. The
output is as follows:
28 SNES Function norm 7.825649542035e-06
0 KSP preconditioned resid norm 5.335581451751e+00 true resid norm
7.825649542035e-06 ||r(i)||/||b|| 1.e+00
1 KSP preconditioned
For a given use case, you may want to try all possible t and c such that t*c=n
: stick to the best one.
Now, if you modify resources (t/c) and you get different timing/iterations,
this seems logical to me: blocks, overlap, ... (and finally convergence) will
differ so comparison does no more
Thank you:)
Few notes on what you wrote
1. I always try to keep t*c=number of cores, however for 64 core KNL
which has hyperthreading switched on (cpuinfo shows 256 cores) t*c
should be 64 or 256 (in other words: is t=64 and c=4 correct?) ?
2. I noticed that for the same input data I
Thank you:)
Few notes on what you wrote
1. I always try to keep t*c=number of cores, however for 64 core KNL
which has hyperthreading switched on (cpuinfo shows 256 cores) t*c
should be 64 or 256 (in other words: is t=64 and c=4 correct?) ?
2. I noticed that for the same input data I
The man page of slurm/sbatch is cumbersome.
But, you may think of :
1. tasks "as MPI processus"
2. cpus "as threads"
You should always set resources the most precise way when possible, that is
(never use --tasks but prefer) to:
1. use --nodes=n.
2. use --tasks-per-node=t.
3. use
10 matches
Mail list logo