The code was submitted to the github
(https://github.com/dealii/code-gallery/pull/92
Oh, doh, my apologies for forgetting about it! I hope to get around to
reviewing it soon!
Best
W.
--
Wolfgang Bangerth
that's good. feel free to discuss any questions related on this topic, I
will get back to you as soon as possible.
syed ansari 于2022年1月25日周二 14:41写道：
> Thank you very much, Mark, for sharing. This is indeed very helpful for me.
>
> Best Regards,
> Syed Ansari S.
>
> On Tue, Jan 25, 2022 at 5:32
Thank you very much, Mark, for sharing. This is indeed very helpful for me.
Best Regards,
Syed Ansari S.
On Tue, Jan 25, 2022 at 5:32 PM Mark Ma wrote:
> Hi,
>
> The code was submitted to the github (
> https://github.com/dealii/code-gallery/pull/92) but is waiting for
> checking. Alternatively
Hi,
The code was submitted to the github (
https://github.com/dealii/code-gallery/pull/92) but is waiting for
checking. Alternatively, you can find the code at my github at:
https://github.com/MarkMa1990/code-gallery/tree/master/Distributed_Moving_Laser_Heating
Have a nice day,
Mark
syed ansari
Thank you very much Prof. Bangerth for your kind reply.
On Sun, Jan 23, 2022 at 10:33 PM Wolfgang Bangerth
wrote:
> On 1/22/22 2:56 AM, syed ansari wrote:
> > I tried to find this code in the deal.ii code gallery but I
> am
> > unable to locate it. I request the group members to hel
On 1/22/22 2:56 AM, syed ansari wrote:
I tried to find this code in the deal.ii code gallery but I am
unable to locate it. I request the group members to help me to find this code.
I don't think it was ever submitted.
Best
W.
--
--
Hello all,
I tried to find this code in the deal.ii code gallery but I am
unable to locate it. I request the group members to help me to find this
code.
Thanks in advance.
Best Regards,
Syed Ansari S.
On Tuesday, October 17, 2017 at 7:46:16 PM UTC+5:30 Wolfgang Bangerth wrote:
> O
On 10/17/2017 07:53 AM, Mark Ma wrote:
Sure, no problem.
Excellent -- let us know if you need help! We're eager to grow the code
gallery!
Best
Wolfgang
--
Wolfgang Bangerth email: bange...@co
Sure, no problem.
2017-10-17 15:23 GMT+02:00 Wolfgang Bangerth :
> On 10/17/2017 07:21 AM, Mark Ma wrote:
>
>>
>> PS: I think this could be another tutorial show how to implement this, I
>> would like to contribute if you think it is interesting for Deal.II project.
>>
>
> Yes, I think that would
On 10/17/2017 07:21 AM, Mark Ma wrote:
PS: I think this could be another tutorial show how to implement this, I would
like to contribute if you think it is interesting for Deal.II project.
Yes, I think that would be great. Or, maybe simpler and with less
documentation requirements: make it a
Hi Wlofgang,
Good news, finally I resolved this problem by assembling the
left_Mass_matrix and right_rhs by the code following,
local_rho_c_T_matrix(i,j) += (rho_C_fun_T.value(fe_values.
quadrature_point(q)) *
phi_i_u *
On 10/16/2017 01:53 PM, Mark Ma wrote:
I think this problem lies in the time updating of solution using
old_solution, since the mass_matrix and laplace_matrix have already
eliminated the constraint node, /*mass_matrix_T.vmult
(system_rhs, old_solution_T_cal*//*);*/ is no longer valid for this
source code are attached.
在 2017年10月16日星期一 UTC+2下午9:14:13，Wolfgang Bangerth写道：
>
> On 10/16/2017 09:23 AM, Mark Ma wrote:
> >
> > It almost looks to me like you're applying both Dirichlet values (via
> > the ConstraintMatrix) and Neumann boundary values (via a boundary
> > integral). But then
> On 10/16/2017 09:23 AM, Mark Ma wrote:
> >
> > It almost looks to me like you're applying both Dirichlet values (via
> > the ConstraintMatrix) and Neumann boundary values (via a boundary
> > integral). But then I haven't taken a look at the code, so I can't
> > really say for sure.
> >
>
On 10/16/2017 09:23 AM, Mark Ma wrote:
It almost looks to me like you're applying both Dirichlet values (via
the ConstraintMatrix) and Neumann boundary values (via a boundary
integral). But then I haven't taken a look at the code, so I can't
really say for sure.
I think I only applied Dirich
在 2017年10月16日星期一 UTC+2下午5:05:20，Wolfgang Bangerth写道：
>
> On 10/16/2017 08:55 AM, Mark Ma wrote:
> >
> > > So when you visualize the solution, the error is at the
> boundary
> > but it looks
> > > correct in the interior?
> > >
> > > Yes, it is. Thereafter, t
On 10/16/2017 08:55 AM, Mark Ma wrote:
> So when you visualize the solution, the error is at the boundary
but it looks
> correct in the interior?
>
> Yes, it is. Thereafter, the error at boundaries does propagate and then
> interfere with the interior.
在 2017年10月16日星期一 UTC+2下午4:31:25，Wolfgang Bangerth写道：
>
>
> > So when you visualize the solution, the error is at the boundary but
> it looks
> > correct in the interior?
> >
> > Yes, it is. Thereafter, the error at boundaries does propagate and then
> > interfere with the interior.
>
So when you visualize the solution, the error is at the boundary but it
looks
correct in the interior?
Yes, it is. Thereafter, the error at boundaries does propagate and then
interfere with the interior.
From the pictures you posted in a follow-up, it looks like the boundary
values
> On 10/15/2017 12:41 PM, Mark Ma wrote:
> >
> > Now the projection of initial values (rewrite the code by manually
> assemble
> > the matrix and system_rhs and calculate) run OK, but the time updating
> of T is
> > not correct, same phenomenon appears. I believe this may arise from the
>
On 10/15/2017 12:41 PM, Mark Ma wrote:
Now the projection of initial values (rewrite the code by manually assemble
the matrix and system_rhs and calculate) run OK, but the time updating of T is
not correct, same phenomenon appears. I believe this may arise from the fact
that direct using matr
Prof. W. Bangerth,
Please find attached source code, where the projection part is ok now, but
time updating of solution part results is incorrect I believe (see boundary
results). This confused me a few weeks and still did not find a solution.
Best,
Mark
在 2017年10月13日星期五 UTC+2下午2:55:04，Wolfga
Prof. Wolfgang Bangerth,
Now the projection of initial values (rewrite the code by manually assemble
the matrix and system_rhs and calculate) run OK, but the time updating of T
is not correct, same phenomenon appears. I believe this may arise from the
fact that direct using matrix vmult (i.e.
Hi Lucas,
I am currently studying of this, if you have some problems or very exciting
process, we could discuss if you would like to share. :)
Best,
Mark
在 2017年10月13日星期五 UTC+2下午4:50:02，Lucas Campos写道：
>
> Dear Wolfgang,
>
> Thank you for your explanation. Currently, I am using a code that was
Dear Wolfgang,
Thank you for your explanation. Currently, I am using a code that was not
written by me, and uses the MatrixTools::apply_boundary_values() approach.
I try to change it to use the ConstraintMatrix one. For that, step-40 seems
to be the best starting point, like Mark did.
Thanks agai
On 10/13/2017 08:39 AM, Lucas Campos wrote:
In general, using MatrixTools::apply_boundary_values() is not the way to go
with MPI programs. Rather, use a ConstraintMatrix and incorporate the
boundary
values into the same object as you do with hanging node constraints.
This is th
Dear Bangerth,
When you mention
In general, using MatrixTools::apply_boundary_values() is not the way to go
> with MPI programs. Rather, use a ConstraintMatrix and incorporate the
> boundary
> values into the same object as you do with hanging node constraints.
This is the way to go due to
On 10/13/2017 02:06 AM, Mark Ma wrote:
later, I changed the control into
|
|
SolverControlsolver_control (5*system_rhs.size(),1e-12*system_rhs.l2_norm())
|
|
this works well for structure size of um or nm. I think previous setting may
lead to a loss of precision so that the results are always i
It is actually my stupid mistake in solvercontrol,
I used
SolverControl solver_control (dof_handler.n_dofs(),1e-12)
This works when the geometry size in the order of 1, but fails at 1e-6, or
even 1e-9. Here I actually want to make a micrometer or nanometer size
structure.
later, I changed the con
On 10/12/2017 03:02 AM, Mark Ma wrote:
Thanks for your useful advice. Finally I solved this problem.
So what was the problem? Maybe we can learn from your example?
Best
W.
--
Wolfgang Bangerth email:
Hi Prof. Wolfgang Bangerth,
Thanks for your useful advice. Finally I solved this problem.
Best,
Mark
2017-10-10 19:50 GMT+02:00 Wolfgang Bangerth :
> On 10/10/2017 11:40 AM, Mark wrote:
>
>>
>> I really appreciate for your quick reply. Now I do as what you said,
>> using VectorTools in setup_sy
On 10/10/2017 11:40 AM, Mark wrote:
I really appreciate for your quick reply. Now I do as what you said,
using VectorTools in setup_system(). It seems working, but there is
still one question that I always find very large values at points near
boundaries, see attached figures. Is there a way
Hi Prof. Wolfgang Bangerth,
I really appreciate for your quick reply. Now I do as what you said, using
VectorTools in setup_system(). It seems working, but there is still one
question that I always find very large values at points near boundaries,
see attached figures. Is there a way to solve t
On 10/10/2017 08:40 AM, Mark Ma wrote:
I want to solve a heat equation in the time domain with distributed memory
using MPI, but the results are incorrect. In order to do so, I reference
tutorial step-23 for time updating method and step-40 for implementing MPI.
May I ask whether my boundary
Dear experienced deal.II users and developers,
I want to solve a heat equation in the time domain with distributed memory
using MPI, but the results are incorrect. In order to do so, I reference
tutorial step-23 for time updating method and step-40 for implementing MPI.
May I ask whether my b
35 matches
Mail list logo
