> On May 8, 2017, at 5:22 PM, Roy Stogner wrote:
>
>
> On Sat, 29 Apr 2017, Rossi, Simone wrote:
>
>> If I understand you correctly, performing more than one AMR step at
>> every timestep is “inefficient”. The strategy should be to run with
>> a fixed locally refined mesh for N timestep, befo
On Sat, 29 Apr 2017, Rossi, Simone wrote:
If I understand you correctly, performing more than one AMR step at
every timestep is “inefficient”. The strategy should be to run with
a fixed locally refined mesh for N timestep, before running a new
adaptive step.
Yes, although N=1 is often reason
Dear Roy,
thanks for your answer.
If I understand you correctly, performing more than one AMR step at every
timestep is “inefficient”.
The strategy should be to run with a fixed locally refined mesh for N timestep,
before running a new adaptive step.
So if I want to compare with a uniform grid
> On Apr 28, 2017, at 11:40 AM, Roy Stogner wrote:
>
>
> On Thu, 27 Apr 2017, Rossi, Simone wrote:
>
>> The run times for 100 timesteps using AMR can be more than 10 times slower
>> than when using a fine uniform grid.
>> For example, with a 16 x 16 x 16 uniform grid, 100 iterations take abou
Dear Vikram,
I switched to the PatchRecoveryErrorEstimator.
The AMR simulations are faster than before, but still much slower than the
uniform mesh case.
Most of the time is still spent in the projections.
Let me know if you have any suggestion.
Thanks a lot for your help,
All the best,
Simone
A
On Thu, 27 Apr 2017, Rossi, Simone wrote:
> The run times for 100 timesteps using AMR can be more than 10 times slower
> than when using a fine uniform grid.
> For example, with a 16 x 16 x 16 uniform grid, 100 iterations take about 18
> seconds with a single processor.
> With AMR, using a 2 x
On Thu, 27 Apr 2017, Vikram Garg wrote:
> It seems it is the projection functions that are computationally
> expensive.
I'm not sure if this is the entire issue, but Vikram's almost
certainly right that this is the main issue.
I have a couple ideas for possible optimizations here; I'll see if I
Hello Rossi,
It seems it is the projection functions that are
computationally expensive. Would it be possible for you to run with the
PatchRecovery estimator, and see if that results in a similar performance ?
Thanks.
> On Apr 27, 2017, at 12:14, Vikram Garg wrote:
>
> Rossi,
Ok, I ran again the tests with different max_h_levels with the perflog enabled.
Let me know if you see anything here.
Thanks,
Simone
NO AMR
-
| libMesh Performance: Alive time=77.5482,
Rossi, yes compiling with perflog should give you all the details as in the
example.
On Thu, Apr 27, 2017 at 10:54 AM, Rossi, Simone
wrote:
> Dear Vikram,
> as in the examples, I am using the libmesh::KellyErrorEstimator.
>
> I’m compiling libmesh with the --enable-perflog option. Does it
Dear Vikram,
as in the examples, I am using the libmesh::KellyErrorEstimator.
I’m compiling libmesh with the --enable-perflog option. Does it automatically
give all the details you have listed in the example?
For the time being, I am attaching two perfLogs I had saved with only “coarse
scale”
Hello Rossi,
Two questions:
1) Which error estimator/indicator are you using to mark elements for
refinement ?
2) Can you send the perfLog output from libMesh ? You might need to
recompile libMesh with the option --enable-perflog.
Looks something like this:
12 matches
Mail list logo
