That's interesting. Seems like it was more about inlining than branch
prediction. Surprising how much difference it made.
On Tuesday, January 5, 2021 at 6:18:38 PM UTC-5 Timo Heister wrote:
> What I forgot to say:
> We used to have something like
>
> if (use_anisotropic_viscosity==true)
> cell(i
o easy
to implement with very little refactoring.
Lastly, this might not be as helpful, but C++20 has the "un/likely"
attribute that can give hints the compiler to favour a branch.
Best regards,
Doug
On Tuesday, January 5, 2021 at 4:48:00 PM UTC-5 blais...@gmail.com wrote:
> Hi
Thanks for the clarification! I initially thought ghost neighbours would
only include face neighbours. That solves the problem.
On Thu, Oct 22, 2020, 09:33 Wolfgang Bangerth
wrote:
> On 10/21/20 7:46 PM, Doug Shi-Dong wrote:
> > Thanks, yes, that should work well for 2D. I actu
gonal to
the corner cells will have a vertex on the boundary, but none of its
neigbor actually lie on the boundary.
Any advice on how to approach this since the current processor would not
find it within its ghost cells?
Doug
On Wednesday, October 21, 2020 at 9:24:35 PM UTC-4 Wolfgang Bangerth
account for all the corners/edges DoFs that might be on a
boundary, but that seems inefficient.
Anyone knows of a better way within deal.II to deal with this?
Best regards,
Doug
On Friday, May 1, 2020 at 7:21:42 PM UTC-4 Wolfgang Bangerth wrote:
> On 5/1/20 5:07 PM, Shahab Golshan wrote:
> &g
type.
I've actually implemented sacado_fad_fad first because I understood it
theoretically. Turns out, it was a bottleneck in my code, so I need
sacado_rad_fad. Might just switch the AD package.
Thanks again, following-up with a documentation PR
https://github.com/dealii/dealii/pull/10818
D
problems.
Please let me know what you think. It's likely completely in the hand of
the Sacado group unless I start digging in their code. However, if it is
something that will likely not get fixed, we might want to put a warning on
the "Supported automatic differentiation libraries&
Yes I can confirm, I am using QProjector with a dummy face Quadrature right
now it works as intended.
Doug
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you
Agreed. Sorry for the confusion. Looked back at my code and it's probably
the most straightforward way.
For some other unrelated reason I didn't want to use FEValues and directly
deal with the Mapping class.
Doug
On Monday, June 22, 2020 at 5:05:57 PM UTC-4, Simon Sticko wro
pass it to
transform_unit_to_real_cell().
Doug
On Sunday, June 21, 2020 at 8:10:30 PM UTC-4, Lex Lee wrote:
>
> Hello Doug,
>
> Thanks for your kind help.
>
> I am trying to understand your suggestion in the original email.
>
> Are you suggesting
lways know whether your point is on the face or not.
Therefore, transform_unit_to_real_cell() should do the trick. Unless you
somehow actually need to project a "volume" point, but projecting within
unit cell is easy, which you would then follow with
transform_unit_to_real_cell().
Bes
.
(ugly code:
https://github.com/dougshidong/PHiLiP/tree/full_space_optimization/src/mesh)
I'd love to hear an update when you succeed
Doug
On Monday, June 8, 2020 at 12:22:08 PM UTC-4, Bruno Blais wrote:
>
> Dear all,
> I hope you are doing well.
>
> In my endless quest
More so, I just found that the AffineConstraints function have not been
instantiated for a mix of TrilinosWrappers::SparseMatrix and
LA::dist::Vector, hence it likely has not been tried out/tested.
Seems like it's just not a thing to use LA::dist::Vector other than for
matrix-free?
--
The dea
erything, am
I expecting too much from it? Maybe I just need to fix the LinearOperator
implementation to mix-and-match the data structure? If I do commit to
Trilinos matrices/vectors, will I have trouble doing some matrix-free or
GPU stuff in the far future?
Best regards,
Doug
--
The deal.II projec
nario where it *doesn't* work well for me is actually in *serial
with hanging nodes*.
I'll report back here with the issue in the upcoming month or on Github
with an issue if I can pinpoint where it comes from.
Doug
On Tuesday, December 31, 2019 at 3:47:23 PM UTC-5, David Wells wro
resulting Trilinos
vector was empty and would of course not have the same parallel
distribution as the matrix it was supposed to be multiplied with.
Doug
On Wednesday, December 4, 2019 at 6:25:49 PM UTC-5, Doug Shi-Dong wrote:
>
> Hello,
>
> I am trying to solve a block syst
with hanging nodes and Dirichlet boundary
condition. I was wondering what I should be careful about. In which
scenarios would those functions fail?
I couldn't find any issues on GitHub regarding those, or any mention of a
specific problem when git blaming.
Happy holidays!
Doug
--
The de
ond to the Trilinos' Vector BlockMap in order to perform the
appropriate matrix-vector multiplication?
Another note: the matrix I'm looking to use is rectangular, and therefore
DomainMap() != RangeMap().
Best regards,
Doug
--
The deal.II project is located at http://www.dealii.org/
Fo
Not sure why it builds fine locally, but that fixed it! Thank you!
Doug
On Wednesday, November 6, 2019 at 11:06:47 AM UTC-5, Wolfgang Bangerth
wrote:
>
> On 11/6/19 8:49 AM, Doug Shi-Dong wrote:
> >
> > Any hints about what could be causing this?
>
> I thought we
e
fixed in the current development version.
Are you aware of anyone hosting a "development" Docker build for their own
continuous integration. I know this can be very expensive to keep up with
the commits. Otherwise, I guess I should just build my own Docker with my
current deal.II fork.
ON, when my CMake
checks for it.
If no MPI is available, how do I compile the code within this Docker
container?
Best regards,
Doug
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received
iency only shows up when using elements of order 4
or more.
Depending on where you want to take your code in the future, I'd be careful
with early code optimization like this. I would just stick with
communicating all the neighbor's dofs and optimize the code if you really
see a s
change line 9062
if (cell->is_locally_owned())
to
if (cell->is_locally_owned() && cell->subdomain_id ==
subdomain_to_integrate)
Not sure if there is a more elegant way.
Doug
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://gr
Prof. Heltai hinted at in the previous
post?
Best regards,
Doug
On Thursday, September 10, 2015 at 2:02:48 AM UTC-4, Praveen C wrote:
>
> Dear all
>
> I would like to use high order meshes for compressible flow computations
> around objects like airfoils. I would like to use G
On Wednesday, September 18, 2019 at 11:28:45 PM UTC-4, Wolfgang Bangerth
wrote:
>
>
> Doug,
>
> It does not greatly surprise me that it doesn't compile -- what isn't
> tested
> generally doesn't work.
>
Makes sense.
We'd of course be very hap
8366)
to
your if with an if-statement that works for refine/distributed grids.
On Wednesday, September 18, 2019 at 12:33:43 AM UTC-4, vachan potluri wrote:
>
> Doug and Praveen,
>
> Thanks for your answers. I had a look at step-33. As far as I understand,
> although the looping
>
> so 'a' is of type Sacado::Fad::DFad. It then needs to call
>
>numbers::is_finite (Sacado::Fad::DFad), which doesn't exist.
> It probably just tries to go through all of the overloads of
> numbers::is_finite() and wants to see whether it can convert the
> argument Sacado::Fad::DFad to t
es/dealii/include/deal.II/lac/la_parallel_vector.templates.h
itself calls AssertIsFinite. e.g. line 1450
In the end, it is basically trying to convert the Sacado type into a
complex number, which is undefined, whenever it tries to perform some
vector operations.
Doug
--
The deal.II project is located
re I can control the metric degrees of freedom?
Doug
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II
f you
only plan on doing linear advection, your problems should be simple enough
that you wouldn't care about memory nor computational time. I haven't seen
people build those global matrices, but it should be faster than assembling
every loop. It's the old trade-off between m
On Monday, September 9, 2019 at 10:13:32 AM UTC-4, Wolfgang Bangerth wrote:
>
> 1.
>
> This seems like we are abusing the real_type for something it wasn't
> intended
> to do. Can you open a github issue with the error message you get with the
> unmodified code?
> 2.
>
> I suspect that that
l will be to automatically differentiate the entire Jacobian
and the sensitivities of the residual with respect to the grid points.
Best regards,
Doug
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
--
On Tuesday, August 27, 2019 at 3:51:20 AM UTC-4, Marc Fehling wrote:
>
>
> The patch has been merged. Let me know if this fix does the trick for you.
>
It does! Thank you again for the quick support.
Doug
--
The deal.II project is located at http://www.dealii.org/
For mailin
Thank you very much for the quick fix! Looking forward to pull this once it
goes through all the checks.
Doug
On Sunday, August 25, 2019 at 9:44:29 AM UTC-4, Marc Fehling wrote:
>
>
> I came up with a fix for this issue in the following PR #8637
> <https://github.com/dealii/d
succeeds for mpirun=4.release...
I have attached the output from ctest.
On Wednesday, August 21, 2019 at 5:39:11 AM UTC-4, Marc Fehling wrote:
>
> Hi Doug!
>
> On Wednesday, August 21, 2019 at 4:00:49 AM UTC+2, Doug wrote:
>>
>> 8134: void dealii::parallel::distr
ls (uncomment line 150) instead of
coarsening them (line 149), the solution transfer is successful. Playing
around with various refinement/coarsening, it seems a bit arbitrary when it
does work and when it won't. Am I calling anything out of order?
Doug
On Sunday, August 18, 2019 at 9:44:50 PM
on way to
do this.
How do you provide tests in the deal.II testsuite to account for different
round-off errors that might occur?
On Monday, August 19, 2019 at 1:17:10 PM UTC-4, Wolfgang Bangerth wrote:
>
> On 8/18/19 10:44 PM, Doug wrote:
> >
> > I'd be happy to add t
et_active_fe_index(), I wouldn't expect to do the
refinement for both DoF handlers at the same time.
I'd be happy to add this test to the list if that's something you are
interested in. I just have to take the time to read through how to.
Anyways, it all works as expected righ
gram.
Try to come up with the smallest possible program that still demonstrates
the error and contact the deal.II mailing lists with it to obtain help.
110:
I went through some of the deal.II source code and it's a bit out of my
depth. Pl
in for your time. Hoping I can get up to speed to contribute
back in the future.
Best regards,
Doug
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscr
should produce optimal orders of convergence.
Thank you for the response, it was immensely helpful.
Doug
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are
truly linear elements.
It's not really an issue for me since I will just switch to a
tensor-product basis. However, I am curious whether or not my understanding
of what is happening is correct, and if this behaviour is expected.
Best Regards,
Doug
--
The deal.II project is located at
Hello Gary,
Since we have two independent implementation of DG, I am curious to know if
you achieve optimal error convergence order of (p+1) on *distorted* grids
for either linear advection, diffusion, or convection-diffusion.
Best Regards,
Doug
On Friday, April 26, 2019 at 11:48:58 AM UTC
Jacobian determinant to avoid re-computation. However, its
effect on the total time should be relatively small compared to flux
computations. "Premature optimization is the root of all evil".
Doug
On Sunday, February 10, 2019 at 2:15:04 PM UTC-5, Wolfgang Bangerth wrote:
>
>
>
(\nabla_{reference} phi) every time reinit(cell) is called. Otherwise, the
solution will be to pre-compute and store those outside in some other
container and avoid using FEValues.
Doug
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://
/I8aLPu5anrM/gBzaaqivDAAJ),
you plan on switching over to Tpetra, which will also be useful for us
since we might instantiate those vectors with AD types. Do you have an idea
of the time horizon on which this will be developped?
Doug
On Wednesday, February 6, 2019 at 9:22:17 AM UTC-5
_generic, and
local integrators, I see that it looks relatively easy to template the
value type since it is already partially templated.
Is there a reason why those functions were not templated? Is there anything
we should be careful about before we start templating those functions?
Doug
--
47 matches
Mail list logo
