On 8/26/24 06:35, Junxiang Wang wrote:
However, In all the tutorials steps of deal.II , the test function is
indexed by "i" loop, right? For example, in the form of local_matrix(
i, j ).
The difference is whether you multiply the equation from the left, or
from the right, by a test funct
Dear Prof. Thomas Wick,
Thanks a lot for your answer. Now, I understand the purpose of your code.
However, In all the tutorials steps of deal.II , the test function is
indexed by "i" loop, right? For example, in the form of local_matrix( i, j
).
Best regards,
Junxiang.
On Monday, August 26
Dear Junxiang Wang,
the reason is that we are dealing with a non-symmetric problem and the
test function determines the row, while trial functions
determine columns of the system matrix.
The quickest and easiest way is to switch those indices to achieve this.
In general, actually, the notatio
Dear Timo Heister Thomas Wick,
I have been reading your paper about phase-field crack propagation and your
code recently. May I ask why your index of assembly subroutine has the form
of local_matrix( j, i ) rather than the normal form of local_matrix( i, j
)?
Thanks a lots
On Tuesday, Febru
Dear Yaakov,
which article do you mean? Please give the exact reference including
author names.
I do not know a priori whether they have different material parameters,
another
stress-strain splitting, etc.
The reason for different results can be anything. One needs to do a
careful 1-by-1
Dear Yaakov,
which article do you mean? Please give the exact reference including
author names.
I do not know a priori whether they have different material parameters,
another
stress-strain splitting, etc.
The reason for different results can be anything. One needs to do a
careful 1-by-1
Dear Prof. Wick,
I have used isotrope formulation for miehe shear loading (without local
refinement). I ca not see two crack branching which is described in the
article (A review on phase-field models of brittle fractureand a new fast
hybrid formulation)
I attach the test results.
Thanks for
Dear Prof. Wick,
thanks a lot for your support.
I will learn how these commands work in the proposed phase-field user
element.
Kind regards,
Yaakov
On Saturday, February 3, 2018 at 7:20:27 AM UTC+1, Thomas Wick wrote:
>
> Hello,
>
> there are two flags in the parameter file that you need to ch
Dear Prof. Wick,
thanks a lot for your support.
I will learn how these commands in your user element works,
Kind regards,
Yaakov
On Saturday, February 3, 2018 at 7:20:27 AM UTC+1, Thomas Wick wrote:
>
> Hello,
>
> there are two flags in the parameter file that you need to change:
>
> set Decomp
Hello,
there are two flags in the parameter file that you need to change:
set Decompose stress in rhs = 0.0
set Decompose stress in matrix = 0.0
Thomas W.
--
++++
Prof. Dr. Thomas Wick
Institut für Angewandte Mathematik (IfA
Dear Prof. Heister,
I would like to just test isotrope formulation of phase -field model (no
compression/tension modification), how could I modify the codes (in a
simple way)?
I am sorry that I am just a beginner of DealII.
Best
On Tuesday, December 5, 2017 at 7:01:17 PM UTC+1, Timo Heister
Dear Prof. Heister,
I would like to test isotrope formulation of phase -field model (no
compression/tension modification), how could I modify the your codes (in a
simple way)?
I am sorry that I am just a beginner of DealII.
Best
On Tuesday, December 5, 2017 at 7:01:17 PM UTC+1, Timo Heister
> If I use your user element, I have to use OPEN MPI? now I have some issues
> with Open MPI in Deal.ii
What do you mean by "user element"? The example code in question
requires deal.II to be configured with MPI. What vendor you use
(OpenMPI, MPICH, ...) is up to you.
--
Timo Heister
http://www.
Timo,
If I use your user element, I have to use OPEN MPI? now I have some issues
with Open MPI in Deal.ii
Regards,
Yaakov
On Thursday, March 30, 2017 at 3:13:16 PM UTC+2, Seyed Ali Mohseni wrote:
>
> Dear Timo Heister and Thomas Wick,
>
> I am trying to run your phase-field crack propagation ex
Hi Daniel,
Thank you very much!
Regards,
Jack
在 2017年5月14日星期日 UTC+8下午5:07:26，Daniel Arndt写道：
>
> Jack,
>
> have a look at https://github.com/tjhei/cracks
>
> Best,
> Daniel
>
> Am Freitag, 12. Mai 2017 07:57:06 UTC+2 schrieb Jack:
>>
>> Hi S. A. Mohseni,
>>
>> I'm also interested on the crackin
Jack,
have a look at https://github.com/tjhei/cracks
Best,
Daniel
Am Freitag, 12. Mai 2017 07:57:06 UTC+2 schrieb Jack:
>
> Hi S. A. Mohseni,
>
> I'm also interested on the cracking mechanics, where is such an example
> for crack propagation ?
>
> Thanks !
>
> 在 2017年3月30日星期四 UTC+8下午9:13:16，Se
Hi S. A. Mohseni,
I'm also interested on the cracking mechanics, where is such an example for
crack propagation ?
Thanks !
在 2017年3月30日星期四 UTC+8下午9:13:16，Seyed Ali Mohseni写道：
>
> Dear Timo Heister and Thomas Wick,
>
> I am trying to run your phase-field crack propagation example, namely the
That’s not the right way to do it, you should have something along the lines:
unsigned int number_of_values () const
{
return 1 + ;
}
virtual void pack_values(std::vector &values) const
{
values[0] = psi;
values[1] = B[0][0];
values[2] = B[0][1];
...
}
and same for unpack b
Dear Denis Davydov,
I am trying to implement the pack_values() and unpack_values() functions
for a FullMatrix, but the function itself in
quadrature_point_data.h is defined using a vector of double values only.
Nevertheless, my initial approach would be the following:
struct MyQData: public Tr
Hi Seyed,
On Sunday, April 9, 2017 at 8:18:10 PM UTC+2, Seyed Ali Mohseni wrote:
>
> Dear Thomas,
>
> Sure, my bad. I am sorry for the inconvenience it may have caused you and
> Timo. Unfortunately, I was just paying attention to the input text file and
> oversaw the changes I actually made. Won
Dear Thomas,
Sure, my bad. I am sorry for the inconvenience it may have caused you and
Timo. Unfortunately, I was just paying attention to the input text file and
oversaw the changes I actually made. Won't happen again. ;)
Regarding the speedup, I just figured out how to make use of the
CellDa
Hi,
I just figured out how to make use of the CellDataStorage function which
has been recently implemented within deal.II. First of all, I want to thank
Denis Davydov and Jean-Paul Pelteret for implementing it so nice and
stable. :) Without your recent work, I probably would have to find a way
Dear Seyed Ali,
very good!
However, when you write that you solve "exactly" my/our (Timo and I)
code then I would assume it is really "exactly" that version.
When you add other things, of course this might accelerate or slow
down the code :)
Next time, please write first if you solve "exactly"
Dear Thomas,
I found the problem. Your version works exactly like discussed in your
paper, even faster with my Intel i7, namely around 1400 s. The
timeconsuming part is the computation of my B-operator.
The B-operator computation is implemented inside* assemble_system (bool
residual_only):*
Hi,
> Each Core i7 CPU has maximum 4 physical cores. So, in MPI mode, solving
> the simulation using 4 core is faster than 8 cores in your computer.
>
This is not true. I checked it, it is slower.
Best,
Seyed Ali
--
The deal.II project is located at http://www.dealii.org/
For mailing list/
Hi
Each Core i7 CPU has maximum 4 physical cores. So, in MPI mode, solving the
simulation using 4 core is faster than 8 cores in your computer.
H.B
On Thursday, April 6, 2017 at 7:44:26 PM UTC+4:30, Seyed Ali Mohseni wrote:
>
> Dear Thomas,
>
> 1. Do you compute on the same mesh?
>>
>
> Yes,
Dear Thomas,
1. Do you compute on the same mesh?
>
Yes, it is exactly the same mesh which is illustrated within your paper:
16384 cells (50115 DoFs). You can observe the same value also in the
terminal output. I selected 4 global pre-refinement steps and 2 adaptive
refinement cycles.
> 2. d
Dear Seyed Ali,
no idea, but possible reasons :
1. Do you compute on the same mesh?
2. do you compile in release mode or debug mode?
Release is faster.
3. Possibly you can optimize deal.Il with respect to the CPU etc.
On my desktop computer at work, deal.II is 2 - 4 times slower than
Dear Thomas,
I was wondering, why my computation is rather slow compared to your results
within your paper. For instance regarding the shear test you mention that
for global refinement the total time amounts to 5036 s. In my case each
step takes around 200 s which would result in a total time o
Dear Seyed Ali,
On 04/01/2017 01:19 PM, 'Seyed Ali Mohseni' via deal.II User Group wrote:
Dear Thomas,
Thank you. I checked the values and they are similar.
Good.
Within your predictor-corrector approach, I assume that you somehow
exchange data between each step in order to be able to int
Dear Thomas,
Thank you. I checked the values and they are similar.
Within your predictor-corrector approach, I assume that you somehow
exchange data between each step in order to be able to interpolate the old
solution. Am I able to use the same functions to store energy data in each
Gauss poi
Dear Seyed Ali,
now I understand better. What you could do is to disable
the phase-field functionality in the program or to
choose G_c very high such that the phase-field will never
be activated. Then you only have the elasticity part
and can compare.
||
By the way Thomas, if you don't rememb
Dear Thomas,
Exactly, I did that already. It seems it is identical, but I would like to
see, if your energy variable psi_e is identical to mine. This is quite
cumbersome for 500 elements or more to check. I mean the computation in the
first steps is anyway independent from the phase-field value
Dear Seyed Ali,
but this does not make sense since the finite
element approximation on one element is far from being meaningful.
Anything you obtain has a huge discretization error.
In addition, this result will not be independent of phase-field.
I would rather do it as we did (and usually done
Dear Thomas,
I would like to check the elastic energy you compute and compare it to my
results. For a single element the computation in an elastic regime should
be independent from the phase-field approach in primary steps.
BR,
Seyed Ali
--
The deal.II project is located at http://www.dealii
Dear Seyed Ali,
what do you mean by "one element test"?
Really to compute on one single element ?
This can never work:
1. First of all the phase-field will not be resolved
because of the regularization parameter eps.
2. This contradicts any idea of numerical methods
to have a reasonab
Dear Thomas,
I tried what you suggested and it works. Thank you :)
There is a slight problem though when I try to compute the same example
with the same boundary conditions for the unit_square_4.inp file. I am
trying to run a one element test using your phase-field approach. It works,
but there
On 03/30/2017 03:38 PM, 'Seyed Ali Mohseni' via deal.II User Group wrote:
Dear Thomas Wick,
I see. So I should change it manually everywhere. I thought the degree
variable will do this automatically, but why did you then implement it
like this? Is it for another purpose?
It is just copy&pas
Dear Thomas Wick,
I see. So I should change it manually everywhere. I thought the degree
variable will do this automatically, but why did you then implement it like
this? Is it for another purpose?
Kind regards,
S. A. Mohseni
--
The deal.II project is located at http://www.dealii.org/
For mai
39 matches
Mail list logo
