[deal.II] Should DEAL_II_LIBRARIES be available via deal.IIConfig.cmake?

[Alex Cobb]

Hi Everybody,

I have been using DEAL_II_LIBRARIES and related variables from
deal.IIConfig.cmake to build Python extensions against deal.II.  These
variables do not seem to be available any longer in installed .cmake files,
unless I am missing something?  However, they are still documented as
existing and available for external use according to the User CMake
configuration page for users
https://www.dealii.org/current/users/cmake_user.html
and for developers
https://www.dealii.org/current/developers/cmake-internals.html

It looks like these variables stopped being exported as of version 9.5.0
due to this commit:
https://github.com/dealii/dealii/commit/800dc279968479e31ac486d99388012e4c9b7b27
which deleted the relevant lines from cmake/config/Config.cmake.in.  I
can't seem to find a specific discussion of this change in the release
notes
https://www.dealii.org/developer/doxygen/deal.II/changes_between_9_4_0_and_9_5_0.html

Is retaining these variables a possibility?  Or is there some reason the
use of these variables (DEAL_II_INCLUDE_DIRS, DEAL_II_LIBRARIES_DEBUG, ...)
should be discontinued by users, in favor of some alternative...?

Thanks and regards

Alex

-- 
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 User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/CAM8c7P2GDzhFimK4Ckso4hb-hQjdsmXz-j_aKALc1gvbqgsFMQ%40mail.gmail.com.

Re: [deal.II] Raviart-Thomas elements on shells in 3D

[Wolfgang Bangerth]

On 11/15/23 13:57, Marc BAKRY wrote:
I won't hesitate. At the moment, I tried to change the template from 
 to  and to make the corresponding 
changes in the FERaviartThomas class; however it seems that it is not 
/that/ easy (I triggered /a lot/ of errors at compile time, among them 
in the FETools namespace).


Having gone through this thing before, my approach is usually "one error 
at a time". It may be a long list, but you'll get them all fixed in due 
time.


Whenever I need to fix something in other files (for example, add 
spacedim template arguments to functions in FETools), I typically end up 
making those into independent pull requests to already get those merged 
so that the final pull request that does what I set out to do is not as 
large any more.


Best
 W.

--
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 User Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/9119f943-6272-44f9-a308-182267dfec7d%40colostate.edu.

[deal.II] Re: Helping collaborators write a cluster module for deal.II

[blais...@gmail.com]

Dear David,
The Digital Alliance of Canada (Compute Canada) has deal.II on their 
cluster through the use of the module system:
https://docs.alliancecan.ca/wiki/Available_software

You could reach out to them and ask them for their module file. They are 
generallly very chill.
If you need help reaching out, ask me and I can write to them with you in 
CC.
Best
Bruno


On Wednesday, November 15, 2023 at 8:00:08 a.m. UTC-5 Wells, David wrote:

> Hi everyone,
>
> I'm working with a group at another university on a deal.II-powered 
> project (yay). I'd like to set things up as a module (i.e., do module load 
> dealii/9.5.1) so that everyone there is using the same version of 
> everything.
>
> Are there any published versions of deal.II modules for various Linux 
> distributions? Every cluster is different but it would be super helpful to 
> see what other people have done to install deal.II and dependencies in this 
> situation.
>
> Best,
> David Wells
>

-- 
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 User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/fc271591-d715-49b8-bdb0-471b8eca38a3n%40googlegroups.com.

Re: [deal.II] Liltle help with MUMPS

[blais...@gmail.com]

In addition to what Wolfgang wrote,
Sometimes the OS will map the cores of a CPU in the following order:
Physical-Logical-Physical-Logical-Physical-Logical etc.
Consequently, if your processor supports hyperthreading through the use of 
logical core, running with core 0-1 means you are essentially running on a 
single physical core but using two logical cores. For intensive operations 
that use the same instruction set, this is generally never a good idea. In 
the present case though, since the assembly is fast but not the matrix 
solve, I would presume it is more a question of memory lane issues than 
anything else. Your CPU might be really memory-bandwith bound.


On Wednesday, November 15, 2023 at 11:39:59 a.m. UTC-5 Wolfgang Bangerth 
wrote:

>
>
> On 11/15/23 04:09, Abbas Ballout wrote:
> > 
> > If I run mpirun -np2 the assemble times are 25.8 seconds and the MUMPS 
> > solve times are 51.7 seconds.
> > If I run mpirun --cpu-set 0-1 -np 2, the assemble times are 26 seconds 
> > (unchanged) but the solve time are at 94.9 seconds!
> > Is this normal and expected?
>
> What happens if you use `--cpu-set 0,2` or other combinations?
>
> Cores have memory channels that they often share with other cores. I 
> wonder whether, for example, cores 0 and 1 share a memory channel and 
> consequently step on each other's toes during the direct solve (which is 
> memory bound). Or they share SIMD execution units. It would be 
> interesting to see what happens if you choose other sets of cores to use.
>
> Best
> W.
>

-- 
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 User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/d4dfee09-df51-4f87-90ad-71b1cd7eea52n%40googlegroups.com.

Re: [deal.II] Raviart-Thomas elements on shells in 3D

[Marc BAKRY]

I won't hesitate. At the moment, I tried to change the template from  to  and to make the corresponding changes in
the FERaviartThomas class; however it seems that it is not *that* easy (I
triggered *a lot* of errors at compile time, among them in the FETools
namespace). As an intermediate step, I think I will first try to generate a
dummy finite element class whose sole purpose is to generate the Hdiv
connectivity on the surface, then use a 2D FERaviartThomas to compute the
shape functions on the reference element. Finally, I'll use a Piola
transform to compute the "true" shape value.

Best regards
M.

Le lun. 13 nov. 2023 à 13:45, blais...@gmail.com  a
écrit :

> If you need any help, feel free to reach out to the deal.II community, we
> are always glad to help
>
>
> On Sunday, November 5, 2023 at 10:37:42 a.m. UTC-5 M. Bakry wrote:
>
>> Dear Wolfgang,
>>
>> thanks very much for your answer. I think I will give it a try when I
>> find some time. Non-C1 manifolds are not an issue in the framework of the
>> BEMs. One can, for example, take a look at this reference
>> .
>>
>> Best regards,
>>
>> M.
>>
>> Le sam. 4 nov. 2023 à 03:45, Wolfgang Bangerth  a
>> écrit :
>>
>>> On 11/3/23 15:06, M. Bakry wrote:
>>> > - it seems that the Piola transform is implemented for the
>>> 'codimension=1'
>>> > case (according to the templatization). Could codim=1 RT elements be
>>> > implemented by computing the RT on the reference quad then by applying
>>> the
>>> > corresponding Piola transform ?
>>>
>>> Marc -- quite possibly. The implementation of the RT element predates
>>> the
>>> codimension-1 functionality by several years, and I suspect that the
>>> major
>>> issue is that nobody has taken the time to convert the implementation to
>>> support surfaces.
>>>
>>> I will note that unless you have a C^1 manifold description -- for
>>> example if
>>> you try to describe a surface by using bilinear quads without using a
>>> manifold
>>> description -- then the normal vectors from adjacent cells are not going
>>> to
>>> point in the same direction (more precisely, they will be tangential to
>>> the
>>> cell, but not to the underlying manifold). In that case, you'll end up
>>> with a
>>> non-conforming RT space because the normal component of the finite
>>> element
>>> field is not continuous across cell interfaces.
>>>
>>> Best
>>>   W.
>>>
>>> --
>>> 
>>> Wolfgang Bangerth  email: bang...@colostate.edu
>>> www:
>>> http://www.math.colostate.edu/~bangerth/
>>>
>>>
>>> --
>>> 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 a topic in the
>>> Google Groups "deal.II User Group" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/dealii/6Z8jBTShIq8/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> dealii+un...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/dealii/5b4695d4-b010-8591-135b-303cd6d27dc7%40colostate.edu
>>> .
>>>
>> --
> 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 a topic in the
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/dealii/6Z8jBTShIq8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/fb6f1fc5-676d-41b2-a143-2ae7bcffb4d2n%40googlegroups.com
> 
> .
>

-- 
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 User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/CADuXRCcAsgewcSzrVv4B5GB9bnA5rjmv6jSwrSxX0oyeQKKeKA%40mail.gmail.com.

Re: [deal.II] Liltle help with MUMPS

[Wolfgang Bangerth]

On 11/15/23 04:09, Abbas Ballout wrote:


If I run mpirun -np2 the assemble times are 25.8 seconds and the MUMPS 
solve times are 51.7 seconds.
If I run mpirun --cpu-set 0-1 -np 2, the assemble times are 26 seconds 
(unchanged) but the solve time are at 94.9 seconds!

Is this normal and expected?


What happens if you use `--cpu-set 0,2` or other combinations?

Cores have memory channels that they often share with other cores. I 
wonder whether, for example, cores 0 and 1 share a memory channel and 
consequently step on each other's toes during the direct solve (which is 
memory bound). Or they share SIMD execution units. It would be 
interesting to see what happens if you choose other sets of cores to use.


Best
 W.

--
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 User Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/9f6610df-6301-430d-97f7-b25b037fa0aa%40colostate.edu.

Re: [deal.II] Re: MGTransferGlobalCoarsening with Nedelec element

[Ce Qin]

Dear Peter,

Thank you very much. I will look into that PR and try to understand it.

Best,
Ce

Peter Munch  于2023年11月15日周三 20:12写道：

> Hi Ce Qin,
>
> There is a WIP PR for adding a fallback path to MGTransferMF:
> https://github.com/dealii/dealii/pull/12924. The PR is already 2 years
> old and has merge conflicts with master. But I guess the changes would be
> similar on master.
>
> Best,
> Peter
>
> On Wednesday, 15 November 2023 at 08:30:00 UTC+1 qinc...@gmail.com wrote:
>
>> Dear all,
>>
>> I want to implement a Multigrid solver with global coarsening for
>> Maxwell's equations.
>> However, upon reviewing the documentation for MGTransferMF, it appears
>> that
>> non-primitive elements are not currently supported. Is there any way to
>> implement
>> global coarsening MG solver with the Nedelec element?
>>
>> Thanks in advance.
>>
>> Best regards,
>> Ce Qin
>>
> --
> 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 User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/55745114-59e1-442d-8da0-761ea3bb40d2n%40googlegroups.com
> 
> .
>

-- 
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 User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/CA%2Bg8s4uD%2B0OkrqtEaCDfC7XKN7GLTiXGb%3D2PuPzuTHG9gVOZXg%40mail.gmail.com.

Re: [deal.II] Importing nodal BCs and accessing vertices

[Alex Quinlan]

Thanks, Wolfgang.  I will abide by those guidelines.

On Tuesday, November 14, 2023 at 10:15:29 PM UTC-5 Wolfgang Bangerth wrote:

> On 11/14/23 16:25, Alex Quinlan wrote:
> > 
> > I'm curious what your thoughts are on this approach.  I imagine it could 
> have 
> > an advantage in some situations, depending on the size of the mesh and 
> the 
> > number of constraints to be added.
> > 
> > I have not done any speed testing on this yet, tho.  Do you think it 
> would be 
> > looking into?  Or do you see some fatal flaw with this approach?
>
> Alex:
> the general approach most professional programmers will ascribe to is to 
> write 
> a version of the code that is intelligible and easy to maintain. Only then 
> do 
> you worry about speed. If the code in question is fast enough (say at most 
> of 
> few percent up to 20% of the program's run time -- as measured with a 
> class 
> such as TimerOutput), then it's not worth worrying about it.
>
> So the questions you're asking are premature. Make the code work what it 
> is 
> you want it to do, and then you can think about its performance.
>
> Best
> W.
>
> -- 
> 
> Wolfgang Bangerth email: bang...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
>
>

-- 
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 User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/08be57a0-9ea9-4726-96e1-22087ca5c3e7n%40googlegroups.com.

[deal.II] Helping collaborators write a cluster module for deal.II

[Wells, David]

Hi everyone,

I'm working with a group at another university on a deal.II-powered project 
(yay). I'd like to set things up as a module (i.e., do module load 
dealii/9.5.1) so that everyone there is using the same version of everything.

Are there any published versions of deal.II modules for various Linux 
distributions? Every cluster is different but it would be super helpful to see 
what other people have done to install deal.II and dependencies in this 
situation.

Best,
David Wells

-- 
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 User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/MN2PR03MB4879818E189AF98CAC9BD780EDB1A%40MN2PR03MB4879.namprd03.prod.outlook.com.

Re: [deal.II] Re: Flag cells to be refined more than one levels?

[Peter Munch]

Hi Greg,

good that you find a working solution! However, I would suggest against 
using `VectorTools::interpolate_to_different_mesd` but use 
`SolutionTransfer` or `parallel::distributed::SolutionTransfer` to move the 
refinement information from a coarse mesh to a fine mesh. You can take a 
look at the tutorial how these classes are used.

Hope this helps,
Peter
On Saturday, 11 November 2023 at 02:24:23 UTC+1 Wolfgang Bangerth wrote:

> On 11/10/23 17:43, Yuan Wang wrote:
> > And I just found that the bug comes from feeding Vector to
> > interpolate_to_different_mesh() while int is not a valid
> > VectorType::value_type therein. Changing int to double fixes it.
>
> Yes, that is right. We do not seem to enforce this, but we are generally 
> expecting Vector to only be instantiated for T=some floating point type.
>
> Best
> W.
>
> -- 
> 
> Wolfgang Bangerth email: bang...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
>
>

-- 
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 User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/3e1b26f7-73fe-45de-922b-81d9fa0d38e3n%40googlegroups.com.

[deal.II] Re: MGTransferGlobalCoarsening with Nedelec element

[Peter Munch]

Hi Ce Qin,

There is a WIP PR for adding a fallback path to MGTransferMF: 
https://github.com/dealii/dealii/pull/12924. The PR is already 2 years old 
and has merge conflicts with master. But I guess the changes would be 
similar on master.

Best,
Peter

On Wednesday, 15 November 2023 at 08:30:00 UTC+1 qinc...@gmail.com wrote:

> Dear all,
>
> I want to implement a Multigrid solver with global coarsening for 
> Maxwell's equations.
> However, upon reviewing the documentation for MGTransferMF, it appears that
> non-primitive elements are not currently supported. Is there any way to 
> implement
> global coarsening MG solver with the Nedelec element?
>
> Thanks in advance.
>
> Best regards,
> Ce Qin
>

-- 
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 User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/55745114-59e1-442d-8da0-761ea3bb40d2n%40googlegroups.com.

Re: [deal.II] In example 40, the results are significantly different between the first-order and second-order finite element meshes

[Abbas Ballout]

ztdep, 
You got me curious 

You can output the results of the Kelly error estimate with something like 
this in the data output: 








*Vector 
estimated_error_per_cell(triangulation.n_active_cells());
KellyErrorEstimator::estimate(dof_handler,QGauss(fe.degree + 1),std::map 
*>(),locally_relevant_solution,estimated_error_per_cell);  
  data_out.add_data_vector(estimated_error_per_cell, "kelly");*

and you'll see that the estimate is horrible with fe(1). Why? because the 
estimate is based on the jump of the gradients across cells and fe(1) isn't 
cutting it 
So if you output the gradient with:


*GradientPostprocessor gradient_postprocessor;
data_out.add_data_vector(locally_relevant_solution, 
gradient_postprocessor);*
(copy paste the postprocessor 
from 
https://www.dealii.org/current/doxygen/deal.II/classDataPostprocessorVector.html)
 

You can see in Paraview that the gradient doesn't look continuous/clean 
across elements when you use fe(1). 
So this isn't weird and unexpected. 

Apparently the gradient approx with bi-linear fe(1) is bad? 
The only way would be for me to be 100% sure would be to write these terms 
down and check for myself. 
If you do it let me know. 


On Monday, November 13, 2023 at 1:45:17 PM UTC+1 blais...@gmail.com wrote:

> Changing to Fe1 really alters the solution, so consequently the kelly 
> error estimator will also give you a different error estimation and thus a 
> different mesh adaptation.
> If your mesh adaptation is based on an error estimator, altering the 
> finite element interpolation order will alter the solution and thus alter 
> the mesh adaptation process.
>
>
> On Monday, November 6, 2023 at 9:13:31 p.m. UTC-5 ztdep...@gmail.com 
> wrote:
>
>>
>> The default setting is  'fe(2)" , we can clearly see a refined region in 
>>  the resulting mesh. While after i changed it to "fe(1)", we cann't see 
>> this region.  
>> This is what i wnat to know .
>> ztdepyahoo
>> ztdep...@gmail.com
>>
>> 
>>  
>>  Replied Message  
>> From Wolfgang Bangerth 
>> Date 11/7/2023 02:59 
>> To  
>> Subject Re: [deal.II] In example 40, the results are significantly 
>> different between the first-order and second-order finite element meshes 
>> On 11/6/23 03:12, ztdep...@gmail.com wrote:
>>
>> **
>>
>> the adaptivited mesh are very diffent as shown in attachments.
>>
>>
>> @ztdep:
>> We don't actually know what you are asking: Your post has no question. We 
>> also 
>> don't know what it is you did: The post doesn't show how you modified 
>> step-40. 
>> Finally, you do not say why you think that the result is wrong or 
>> surprising: 
>> You just show a picture, but for all we know this may be correct.
>>
>> Please spend a bit of thought in formulating questions in such a way that 
>> it 
>> is clear what you are asking, why you are asking it, and what is behind 
>> the 
>> question you are asking.
>>
>> Best
>> W.
>>
>> -- 
>> 
>> Wolfgang Bangerth  email: bang...@colostate.edu
>> www: http://www.math.colostate.edu/~bangerth/
>>
>>
>> -- 
>> 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 a topic in the 
>> Google Groups "deal.II User Group" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/dealii/VcsXMXhl_YQ/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> dealii+un...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/dealii/e17928b7-f1d0-e5f2-83b9-872ba95e492a%40colostate.edu
>> .
>>
>

-- 
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 User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/0a611a56-c142-4153-8220-f42c394bcb00n%40googlegroups.com.

[deal.II] Liltle help with MUMPS

[Abbas Ballout]

This isn't a dealii problem per-se. 

I am trying to run a number of simulations with different parameters of the 
same code with the underlying solver being MUMPS. I am using  *mpirun 
--cpu-set * to bind and isolate the different simulations to different 
cores (As I believe I should) 

*Profiling: *
The number of dofs are something like 262,144, the assemble function is 
called 25 times and the solve function is called 20 times. The solve 
function is using MUMPS nothing fancy is happening there. 
If I run mpirun -np2 the assemble times are 25.8 seconds and the MUMPS 
solve times are 51.7 seconds. 
If I run mpirun --cpu-set 0-1 -np 2, the assemble times are 26 seconds 
(unchanged) but the solve time are at 94.9 seconds! 
 
Is this normal and expected? 

*Maybe relevant details: *
I have 4 physical cores. I am on ubuntu. PETScVectors and  PETScWrappers::
SparseDirectMUMPS 


-- 
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 User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/24f65840-62f0-4d73-b9e0-06a2770ad7f0n%40googlegroups.com.