Yep that does it! Thanks for your patience :)
On Friday, September 16, 2016 at 7:28:41 PM UTC+2, Bruno Turcksin wrote:
>
> Alex,
>
> before the run command, you need to use: catch throw
>
> Best,
>
> Bruno
>
> On Friday, September 16, 2016 at 1:21:41 PM UTC-4, Alex Zimmerman wrote:
>>
>> A couple
True, I've checked in the master and it is templated for the
Function too. I use 8.4.1.
It's fine then. Thanks.
On Friday, September 16, 2016 at 5:39:33 PM UTC+1, Wolfgang Bangerth wrote:
>
> On 09/15/2016 05:12 AM, dragn...@gmail.com wrote:
> >
> > One more question, in fact a small inconsis
Alex,
before the run command, you need to use: catch throw
Best,
Bruno
On Friday, September 16, 2016 at 1:21:41 PM UTC-4, Alex Zimmerman wrote:
>
> A couple of times now I have encountered GDB output similar to my attached
> snapshot.
>
> The previous time I had only made a very small change
A couple of times now I have encountered GDB output similar to my attached
snapshot.
The previous time I had only made a very small change to my code, so it was
easy enough for me to figure out on my own. Presently I'm trying to run a
1D version of my code for the first time. So far I've only r
On 09/15/2016 05:12 AM, dragniko...@gmail.com wrote:
One more question, in fact a small inconsistency that is of my interest:
the function VectorTools::interpolate_boundary_values is not templated
for the generic Number type but for double only (argument
std::map& boundary_values). Is there a
re
Timo, when I looked into this before posting my question, it seemed to be a
pretty clear issue with the perl command not working on the Windows
filesystem. Per my recent reply to Wolfgang, I have moved forward with a
simple work-around (which simply does not involve running ctest on the
Windows
Wolfgang, thanks for pointing me to this part of the code. I'm not sure
when I'll try to fix the problem, because it was very simple to just only
ever run ctest on the Linux filesystem, completely circumventing it. I'll
make sure to post an update if I ever fix this so that I can run ctest on
t
Bruno,
Yeah, I noticed an old discussion with the same problem and solved it.
Thanks,
Weixiong
在 2016年9月16日星期五 UTC-5上午10:42:30,Bruno Turcksin写道:
>
> Weixong,
>
> On Friday, September 16, 2016 at 11:35:09 AM UTC-4, Weixiong Zheng wrote:
>>
>> When running the program, the solution is zero on th
Weixong,
On Friday, September 16, 2016 at 11:35:09 AM UTC-4, Weixiong Zheng wrote:
>
> When running the program, the solution is zero on the left side as
> expected. However, the right side solution is something nonzero. Since I am
> using the same apply_boundary_condition settings, I am suppose
Dear all,
I just tried to modify step-3 to 1D. The changes are minor.
The equation is changed to be with a small reaction.
The mesh is generated with subdivided_hyper_cube (triangulation, 50, 0,
10); I changed all the <2>, the dimension, to <1>.
When running the program, the solution is zero o
Hi, sorry for this late reply. I missed it and realized just now. I found
the problem, which is simply that if the whole system is fully periodic ( I
mean, for example from plane to torus topology) then the 4 corners become
effectively fixed (the other possibility would be rigid body motion). Th
A useful flag that I use in release mode is -funsafe-loop-optimizations,
which assumes that loop counters cannot overflow and other such things. I
don't remember the exact numbers but I do remember that using this flag
made a small, but measurable, performance improvement.
On Thursday, Septembe
I have created a pull request here: https://github.com/dealii/dealii/pull/3123
Thanks again
Bruno
2016-09-16 10:01 GMT-04:00 Bruno Turcksin :
> 2016-09-16 9:22 GMT-04:00 Vaibhav Palkar :
>>
>> The error being exactly zero is indeed intriguing. I'm still looking out for
>> the reason why that is
2016-09-16 9:22 GMT-04:00 Vaibhav Palkar :
>
> The error being exactly zero is indeed intriguing. I'm still looking out for
> the reason why that is happening. I didn't understand what you meant by a
> "ramp in time". Could you please elaborate?
Since you are using a low order method in time, I am
On Friday, September 16, 2016 at 1:38:57 AM UTC+5:30, Bruno Turcksin wrote:
> I don't see anything wrong. The output says that your error is zero,
> are you doing a simple ramp in time? It's very strange that the error
> is exactly zero. What happens if you just use the default parameters?
> D
Jiaqi,
Currently you can access first, second and third partial derivatives in
FEValues. The FiniteElement class also implements fourth derivatives.
If this is sufficient for your purposes, then using
FEValues*::third_derivative should be fine for you. I don't see a easier
way at the moment.
B
16 matches
Mail list logo