Hi Seyed,
I am old-fashioned in this sense: indeed yes, I just plot the output
into a file:
make run | tee my_results.txt
Then I `grep' the quantity (for example PStress) that I want and then
plot with gnuplot.
Of course it would be a bit more efficient to write all output of
interest dir
Dear Thomas,
Would you be so kind to tell me how am I able to create the
load-displacement curves like in your paper? Did you use gnuplot?
And does deal.II have a built-in function that allows one to output the
necessary data directly to gnuplot or to a textfile?
Thank you in advance.
Kind reg
Thanks, that helps a lot.
So the QGaussLobatto or QIterated (from the compute_cod_array() function)
stay unchanged? In how far does changing them affect the computation?
Best,
Seyed Ali
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://gro
On 05/31/2017 05:00 PM, 'Seyed Ali Mohseni' via deal.II User Group wrote:
The only thing I changed a bit is the integration from quadratic to
linear, but I am not sure, if seeting quadrature_formula(2)
In
https://github.com/tjhei/cracks/blob/master/cracks.cc
line 982,
you need to chang
On 05/31/2017 05:00 PM, 'Seyed Ali Mohseni' via deal.II User Group wrote:
I did another trick: Increasing G_c has the same effect to achieve
purely elastic behavior. So, I chose a high enough G_c value and it
works!
I obtain the same results and the duh values grow correctly.
Excellent. Thi
I did another trick: Increasing G_c has the same effect to achieve purely
elastic behavior. So, I chose a high enough G_c value and it works!
I obtain the same results and the duh values grow correctly.
Still I cannot understand fully why when cracking is initiated, there is no
increase of the
I hope you could explain me what could cause such a behavior in your
implementation that deal.II gives different values for duh although
the same postprocessor implementation is being used.
Is it because of the coupled formulation?
I really would think so. What you could do is to disable th
Hi again,
Nice words, indeed. Thank you. I will follow your advice :)
But to get back to the topic: Unfortunately, you misunderstood my problem.
The issue is with the displacement gradient values stored in "duh" which is
computed by deal.II and given as input for the postprocessing tasks to be
Hi Toby,
I appreciate your additional comments.
Thanks and best,
Thomas
On 05/31/2017 02:16 PM, Tobi Young wrote:
I'm going to jump in with one of my random comments uninvited.
Hopefully you don't mind. :-)
I already run the example with uniform mesh, hence global
refinement with 0
I'm going to jump in with one of my random comments uninvited. Hopefully
you don't mind. :-)
I already run the example with uniform mesh, hence global refinement with 0
refinement cycles.
The problem is, a specimen with 100 or 1000 elements is difficult to check
due to the terminal output being f
On 05/31/2017 01:31 PM, 'Seyed Ali Mohseni' via deal.II User Group wrote:
Dear Thomas,
I already run the example with uniform mesh, hence global refinement
with 0 refinement cycles.
The problem is, a specimen with 100 or 1000 elements is difficult to
check due to the terminal output being fl
Dear Thomas,
I already run the example with uniform mesh, hence global refinement with 0
refinement cycles.
The problem is, a specimen with 100 or 1000 elements is difficult to check
due to the terminal output being flooded.
I could just output the result for one element, but then wheres the
di
12 matches
Mail list logo
