On 1/5/21 11:32 AM, Zachary Streeter wrote:
Yes, I want to use the constructor with the dynamic sparsity pattern. So with
your suggestion in mind, would that just be the following:
dealii::IndexSet local_owned(a_local_row_set.size());
local_owned.add_range(*a_local_row_set.begin(),
Dear all
I could compile the latest dealii master branch, which is good for me.
You can ignore my previous message.
Thanks
praveen
> On 06-Jan-2021, at 8:40 AM, Praveen C wrote:
>
> Dear all
>
> I am running into lot of possibly clang errors when installing dealii-9.2
>
> It fails at this p
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
Hello Prof. Blais,
Optimizing code is always fun, so I've had this discussion multiple times
with a colleague. Dr. Turcksin comment was also our conclusion. Templating
seems to be the way to go, but only on options/variations where
mispredicted branches actually slow down your performance since
What I forgot to say:
We used to have something like
if (use_anisotropic_viscosity==true)
cell(i,j) += viscosity_tensor *
else
cell(i,j) += viscosity_constant *
and improved the performance by making two separate assemblers (note
that there is no function call/vtable lookup here, ju
Hi Timo,
I understand. It makes a lot of sense.
Thanks!
Bruno
On Tuesday, January 5, 2021 at 4:34:19 p.m. UTC-5 Timo Heister wrote:
> Hi Bruno,
>
> We mitigate the performance problem by making the decision per cell in
> ASPECT:
> We have a set of "assemblers" that are executed one after each o
Hi Bruno,
We mitigate the performance problem by making the decision per cell in ASPECT:
We have a set of "assemblers" that are executed one after each other
per cell. This means the vtable access cost is small compared to the
actual work.
See
https://github.com/geodynamics/aspect/blob/b9add5f5317
Bruno,
Thanks, you are right. As always, measure first and then optimize after. No
point in optimising stuff that costs nothing...
On Tuesday, January 5, 2021 at 3:15:06 p.m. UTC-5 bruno.t...@gmail.com
wrote:
> Bruno,
>
> If you are worry about the cost of looking up though the vtable, I thin
Bruno,
If you are worry about the cost of looking up though the vtable, I think
that you are stuck using template. So either use 2 or 3 and CRTP. But first
of all, I think that you should profile your code and verify that this is a
problem. There is no point in spending time refactoring your co
W.,
Ah okay I see, I will try that in my program and let you know.
Yes, I want to use the constructor with the dynamic sparsity pattern. So
with your suggestion in mind, would that just be the following:
dealii::IndexSet local_owned(a_local_row_set.size());
local_owned.add_range(*a_local_row
On 1/5/21 8:21 AM, Zachary Streeter wrote:
Let me know if this is okay. This compiled, ran, and produced the same error
on my end.
Yes, that's the sort of testcase that makes it easy to debug :-)
In this call,
m_H1.reinit(MPI_COMM_WORLD,
a_local_row_set.size(),
a
#include
#include
#include
#include
#include
using namespace dealii;
class OneBodyHamiltonianOperator
{
public:
/**
* Declare type for container size.
*/
using size_type = dealii::types::global_dof_index;
OneBodyHamiltonianOperator(const dealii::IndexSet &a_local_row_set,
My project is in quantum scattering and I would like to have some operators be
distributed PETSc objects. So inside my OneBodyHamiltonianOperator class (for
example), I would like to create a PETScWrappers::MPI::SparseMatrix and then
use SLEPC to solve for the ground state and excited states
13 matches
Mail list logo
