Re: [deal.II] Installation on cray XC50 | linking to petsc, lapack and blas libraries with different names

2020-02-11 Thread Jean-Paul Pelteret
Hi Vachan,

If you’re still not having any luck with this, then maybe you’d consider 
investigating deal.II through Spack. There’s in fact a whole section in their 
documentation dedicated to explaining how package installation is done on Cray 
systems:
https://spack.readthedocs.io/en/latest/getting_started.html#spack-on-cray 


Best,
Jean-Paul

> On 12 Feb 2020, at 06:24, vachan potluri  wrote:
> 
> Step-1 aborts with Illegal Instruction (core dumped). The error msg gdb 
> prints is the following.
> Program received signal SIGILL, Illegal instruction.
> __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535)
> at 
> /home/ComptGasDynLab/vachanpotluri/source/dealii-9.1.1/source/numerics/time_dependent.cc:1196
> 1196   std::make_pair(0U, 
> 0.)));
> When I backtrace the error, it leads to this.
> template  
> typename TimeStepBase_Tria_Flags::RefinementFlags::CorrectionRelaxations
>   
> TimeStepBase_Tria_Flags::RefinementFlags::default_correction_relaxations(
> 1, // one element, denoting the first and all subsequent sweeps
> std::vector>(1, // one element, denoting 
> the
> // upper bound for the
> // following relaxation
>  std::make_pair(0U, 0.)));
> Not just step-1, but step.debug, affinity.debug and mpi.debug (and possibly 
> other debug tests may) also terminate with the same error and bt. Can someone 
> explain why this is happening?
> 
> -- 
> 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/9fce9f67-4040-44c3-89c2-bae0effe339a%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/126EAA52-F127-433F-B6E3-C844519372E4%40gmail.com.


[deal.II] Re: Installation on cray XC50 | linking to petsc, lapack and blas libraries with different names

2020-02-11 Thread vachan potluri
Step-1 aborts with Illegal Instruction (core dumped). The error msg gdb 
prints is the following.
Program received signal SIGILL, Illegal instruction.
__static_initialization_and_destruction_0 (__initialize_p=1, 
__priority=65535)
at 
/home/ComptGasDynLab/vachanpotluri/source/dealii-9.1.1/source/numerics/time_dependent.cc:1196
1196  std::make_pair(0U, 
0.)));
When I backtrace the error, it leads to this.
template  
typename 
TimeStepBase_Tria_Flags::RefinementFlags::CorrectionRelaxations
  
TimeStepBase_Tria_Flags::RefinementFlags::default_correction_relaxations(
1, // one element, denoting the first and all subsequent sweeps
std::vector>(1, // one element, 
denoting the
// upper bound for the
// following relaxation
 std::make_pair(0U, 0.)));
Not just step-1, but step.debug, affinity.debug and mpi.debug (and possibly 
other debug tests may) also terminate with the same error and bt. Can 
someone explain why this is happening?

-- 
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/9fce9f67-4040-44c3-89c2-bae0effe339a%40googlegroups.com.


Re: [deal.II] Re: Installation on cray XC50 | linking to petsc, lapack and blas libraries with different names

2020-02-11 Thread Wolfgang Bangerth

On 2/11/20 12:09 AM, vachan potluri wrote:


However, make test shows all tests failing with the error
/bin/sh: .: command not found.
When I navigated to tests/quick_tests and individually ran the tests, 
the output was as follows.

$ ./lapack.debug
Illegal instruction

Can anyone help me with this issue? Is this because I have 
cross-compiled? The make test instruction was run on login node. It so, 
is there a way I check my installation on login node itself without 
needing submitting a job?


Yes, that's exactly the problem: The compiler compiles the library for 
the target nodes, not for the front-end login node. There isn't a good 
way to test things in this case -- I'd just see whether you can run 
something like step-1 on the compute nodes by submitting a job.


You're discovering why the Cray XC machines are so tremendously 
unpopular: Cray managed to create a software system with the many 
support libraries that is incredibly complicated and, moreover, 
incompatible with the way software is set up on almost every other 
machine. It's also exceedingly impractical that they chose a different 
processor for the frontend than for the compute nodes. Both of these 
decisions are really beyond essentially everyone's imagination who has 
to deal with these machines. I don't know a single person who believes 
that these were good design choices for Cray to make.


I don't wish Cray bankruptcy, but I do hope that the tens or hundreds of 
thousands of dollars that are spent on the difficulty of installing 
software on each one of their machines is deducted from the salaries of 
those responsible for their machine designs...


Best
 W.

--

Wolfgang Bangerth  email: bange...@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/a9c22e81-c47e-1d2f-baeb-ddbb84e3c3f9%40colostate.edu.


Re: [deal.II] Running multiple programs at the same time

2020-02-11 Thread Ahmad Shahba
I was just wondering how much I/O operations contribute to your timings.
What would happen if you minimize the I/O activities, maybe comment out
output_results method and see if anything changes?

Regards
Ahmad

On Tue, Feb 11, 2020 at 16:27 Toni Vidal  wrote:

> Hi David,
>
> That did not solve the problem with step 6. I got the same times.
>
> Indeed I have installed deal.II without  threads (DEAL_II_WITH_THREADS =
> OFF) and I set in my .basrc OMP_NUM_THREADS=1.
>
> Any other idea?
>
>
> El dimarts, 11 febrer de 2020 17:53:53 UTC+1, David Wells va escriure:
>>
>> Hi Toni,
>>
>> I think that this is due to each individual program creating the same
>> number of threads as you have physical processors. Try adding
>>
>> MultithreadInfo::set_thread_limit(1);
>>
>> at the top of your code to prevent this from happening. Let us know if
>> this works!
>>
>> Thanks,
>> David
>>
>> On Tue, Feb 11, 2020 at 11:45 AM Toni Vidal 
>> wrote:
>> >
>> >
>> > Dear deal.ii users and developers,
>> >
>> > I am currently running a deal.II based code thousands of times with
>> different input parameters. Each  simulation takes about 30 seconds in a
>> single processor. To do this, I have made a python script that runs 4
>> simulations at a time (using the multiprocessing module). However, each
>> simulation takes about 60 seconds and my have 8 cores (Intel® Core™
>> i7-9700K CPU @ 3.60GHz × 8).  Is it not supposed to take approximately the
>> same amount of because the processors are independent? Am I
>> >
>> > In order to isolate the problem I have executed deal.II's step 6 (with
>> 12 cycles and 1e5 maximum solver steps) 1, 2 and 4 times at the same (using
>> different terminals).
>> >
>> > 1 running programs ~ 32 s user time
>> > 2 running programs ~ 44 s user time
>> > 4 running programs ~ 80 s user time
>> >
>> > Why the programs does not take the same time even though my computer
>> have 8 cores?
>> > Any idea? Am I missing something obvious?
>> >
>> > Ton Vidal
>> >
>> > --
>> > 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 dea...@googlegroups.com.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/dealii/767ae142-a02d-4bc2-a454-d4c385d1b217%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/36de50e0-355b-4337-a9ad-0512229a2f80%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/CAGCgw4BoXcaHis-KAeVHc0v8fU9mSY8okBqcftZ4%2BTikq3QuvA%40mail.gmail.com.


Re: [deal.II] Running multiple programs at the same time

2020-02-11 Thread Wolfgang Bangerth

On 2/11/20 2:27 PM, Toni Vidal wrote:


That did not solve the problem with step 6. I got the same times.

Indeed I have installed deal.II without  threads (DEAL_II_WITH_THREADS = 
OFF) and I set in my .basrc OMP_NUM_THREADS=1.


There are many other possible reasons for contention. For example, most 
finite element programs are limited by the transfer of data from memory 
to the processor. If you have just one program running, then only one 
program is using the memory bus and is getting its full speed. But if 
you have multiple programs running, then they are all competing for the 
same bandwidth on the memory bus, and they will also be slowed down by 
more than a single program would be.


It could also be that you have, say, 4 cores on your processor but 3 
other programs currently running. Then running one instance of your code 
will get a full core, but if you ran four, the total of 7 codes would 
have to compete for 4 cores, and all would be slowed down.


By the way, to see whether your program really is using only one thread, 
you can run the program 'top' in a separate command line window. It will 
show you which percentage of a processor each running job takes up.


Best
 W.


--

Wolfgang Bangerth  email: bange...@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/e22bbfbd-220e-879b-9e7b-0c6eedcd001f%40colostate.edu.


Re: [deal.II] Running multiple programs at the same time

2020-02-11 Thread Toni Vidal
Hi David,

That did not solve the problem with step 6. I got the same times.

Indeed I have installed deal.II without  threads (DEAL_II_WITH_THREADS = 
OFF) and I set in my .basrc OMP_NUM_THREADS=1.

Any other idea?


El dimarts, 11 febrer de 2020 17:53:53 UTC+1, David Wells va escriure:
>
> Hi Toni, 
>
> I think that this is due to each individual program creating the same 
> number of threads as you have physical processors. Try adding 
>
> MultithreadInfo::set_thread_limit(1); 
>
> at the top of your code to prevent this from happening. Let us know if 
> this works! 
>
> Thanks, 
> David 
>
> On Tue, Feb 11, 2020 at 11:45 AM Toni Vidal  > wrote: 
> > 
> > 
> > Dear deal.ii users and developers, 
> > 
> > I am currently running a deal.II based code thousands of times with 
> different input parameters. Each  simulation takes about 30 seconds in a 
> single processor. To do this, I have made a python script that runs 4 
> simulations at a time (using the multiprocessing module). However, each 
> simulation takes about 60 seconds and my have 8 cores (Intel® Core™ 
> i7-9700K CPU @ 3.60GHz × 8).  Is it not supposed to take approximately the 
> same amount of because the processors are independent? Am I 
> > 
> > In order to isolate the problem I have executed deal.II's step 6 (with 
> 12 cycles and 1e5 maximum solver steps) 1, 2 and 4 times at the same (using 
> different terminals). 
> > 
> > 1 running programs ~ 32 s user time 
> > 2 running programs ~ 44 s user time 
> > 4 running programs ~ 80 s user time 
> > 
> > Why the programs does not take the same time even though my computer 
> have 8 cores? 
> > Any idea? Am I missing something obvious? 
> > 
> > Ton Vidal 
> > 
> > -- 
> > 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 dea...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/767ae142-a02d-4bc2-a454-d4c385d1b217%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/36de50e0-355b-4337-a9ad-0512229a2f80%40googlegroups.com.


[deal.II] Re: Error in make_hanging_node_constraints() while using parallel::distributed::Triangulation with hp::DoFHandler

2020-02-11 Thread Marc Fehling
Hi Chaitanya,

This should've been fixed in #8365 
, which is not included in 
deal.II-9.1.1.


Compiling the most recent version of deal.II from the master branch should 
do the trick.


Marc

-- 
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/890e2de7-4fce-45a7-ac3f-9534ef35270a%40googlegroups.com.


Re: [deal.II] Error in make_hanging_node_constraints() while using parallel::distributed::Triangulation with hp::DoFHandler

2020-02-11 Thread David Wells
Hi Chaitanya,

I apologize that no one has answered your question yet. Using
hp::DoFHandler with distributed triangulations is a new feature that
is not yet in a current release and there may still be some bugs in
the implementation. I suspect no one has responded to this simply
because no one knows the answer.

It's not a great solution but would it be possible to use
parallel::shared::Triangulation for your application as a stopgap
measure while we try to figure this out? That should work correctly
with hp::DoFHandler.

Thanks,
David

On Wed, Feb 5, 2020 at 11:44 AM Chaitanya Dev  wrote:
>
> Dear Deal.II Community,
>
> I am trying to use parallel::distributed::Triangulation with hp::DoFHandler. 
> I run into the below error in DoFTools::make_hanging_node_constraints..
>
> I work on shape optimization using embedding domain discretization 
> techniques. In my problems, I have to repeatedly refine the mesh and 
> approximate the geometry. Then I assign different FESystem for the cells 
> within and outside the geometry.
>
> I have implemented the code in serial with serial triangulation and 
> hp::DoFHandler and the program works.
>
> Now I wish to solve larger problems so I have decided to parallelize the code 
> and hence I use parallel::distributed::Triangulation.
>
> Here I run into a problem in system_setup, specifically in the function 
> DoFTools::make_hanging_node_constraints.
>
> Hear is the error message.
> 
> An error occurred in line <1119> of file 
> 
>  in function
> void dealii::DoFTools::internal::make_hp_hanging_node_constraints(const 
> DoFHandlerType&, dealii::AffineConstraints&) [with DoFHandlerType = 
> dealii::hp::DoFHandler<2, 2>; number = double]
> The violated condition was:
> cell->face(face)->child(c)->n_active_fe_indices() == 1
> Additional information:
> This exception -- which is used in many places in the library -- usually 
> indicates that some condition which the author of the code thought must be 
> satisfied at a certain point in an algorithm, is not fulfilled. An example 
> would be that the first part of an algorithm sorts elements of an array in 
> ascending order, and a second part of the algorithm later encounters an 
> element that is not larger than the previous one.
>
> There is usually not very much you can do if you encounter such an exception 
> since it indicates an error in deal.II, not in your own program. 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.
>
> Stacktrace:
> ---
> #0  
> /opt/dealii-9.1.1/opt/spack/linux-ubuntu18.04-haswell/gcc-7.4.0/dealii-9.1.1-holxtax5bwynpjaccyvwkli2ybveslrl/lib/libdeal_II.g.so.9.1.1:
>  void 
> dealii::DoFTools::internal::make_hp_hanging_node_constraints  2>, double>(dealii::hp::DoFHandler<2, 2> const&, 
> dealii::AffineConstraints&)
> #1  
> /opt/dealii-9.1.1/opt/spack/linux-ubuntu18.04-haswell/gcc-7.4.0/dealii-9.1.1-holxtax5bwynpjaccyvwkli2ybveslrl/lib/libdeal_II.g.so.9.1.1:
>  void 
> dealii::DoFTools::make_hanging_node_constraints, 
> double>(dealii::hp::DoFHandler<2, 2> const&, 
> dealii::AffineConstraints&)
> #2  hp-dist-test: TestProblem<2>::setup_system()
> #3  hp-dist-test: TestProblem<2>::run()
> #4  hp-dist-test: main
> 
>
> This is my setup_system function.
>
> template
> void TestProblem::setup_system() {
>
> dof_handler.initialize(triangulation, fe_collection);
>
> for (auto cell : dof_handler.active_cell_iterators()) {
> if (!cell->is_locally_owned())
> continue;
> if (cell->user_flag_set())
> cell->set_active_fe_index(0);
> else
> cell->set_active_fe_index(1);
> }
>
> dof_handler.distribute_dofs(fe_collection);
> locally_owned_dofs = dof_handler.locally_owned_dofs();
> DoFTools::extract_locally_relevant_dofs(dof_handler, locally_relevant_dofs);
>
> hanging_node_constraints.clear();
> hanging_node_constraints.reinit(locally_relevant_dofs);
>
> DoFTools::make_hanging_node_constraints(dof_handler,
> hanging_node_constraints);
> hanging_node_constraints.close();
> }
>
> I did some debugging and found that the Assert fail 
> cell->face(face)->child(c)->n_active_fe_indices() == 1 is failing on the 
> ghost cells. To avoid this error  I tried to set_active_fe_index for the 
> ghost cells, but this is not allowed.
>
> Please let me know where I am going wrong.
>
> I have attached a MWE. You can reproduce the error with mpirun for np >= 2 
> cores (the code will work for np=1, because no ghost cells).
>
> Thank you,
> Chaitanya Dev.
>
> --
> 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 dea

Re: [deal.II] Running multiple programs at the same time

2020-02-11 Thread Wolfgang Bangerth

On 2/11/20 9:53 AM, David Wells wrote:

I think that this is due to each individual program creating the same
number of threads as you have physical processors.


In other words, by default deal.II uses multiple threads to run some 
things in parallel.


Best
 W.

--

Wolfgang Bangerth  email: bange...@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/91557b72-42e3-e569-8737-220f1ce142c0%40colostate.edu.


Re: [deal.II] Running multiple programs at the same time

2020-02-11 Thread David Wells
Hi Toni,

I think that this is due to each individual program creating the same
number of threads as you have physical processors. Try adding

MultithreadInfo::set_thread_limit(1);

at the top of your code to prevent this from happening. Let us know if
this works!

Thanks,
David

On Tue, Feb 11, 2020 at 11:45 AM Toni Vidal  wrote:
>
>
> Dear deal.ii users and developers,
>
> I am currently running a deal.II based code thousands of times with different 
> input parameters. Each  simulation takes about 30 seconds in a single 
> processor. To do this, I have made a python script that runs 4 simulations at 
> a time (using the multiprocessing module). However, each simulation takes 
> about 60 seconds and my have 8 cores (Intel® Core™ i7-9700K CPU @ 3.60GHz × 
> 8).  Is it not supposed to take approximately the same amount of because the 
> processors are independent? Am I
>
> In order to isolate the problem I have executed deal.II's step 6 (with 12 
> cycles and 1e5 maximum solver steps) 1, 2 and 4 times at the same (using 
> different terminals).
>
> 1 running programs ~ 32 s user time
> 2 running programs ~ 44 s user time
> 4 running programs ~ 80 s user time
>
> Why the programs does not take the same time even though my computer have 8 
> cores?
> Any idea? Am I missing something obvious?
>
> Ton Vidal
>
> --
> 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/767ae142-a02d-4bc2-a454-d4c385d1b217%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/CABrTbYQ%3DYHzF9cSyaPtWjo6AUr3TqQntxs5JDYtmAfi0Xusogg%40mail.gmail.com.


[deal.II] Running multiple programs at the same time

2020-02-11 Thread Toni Vidal

Dear deal.ii users and developers,

I am currently running a deal.II based code thousands of times with 
different input parameters. Each  simulation takes about 30 seconds in a 
single processor. To do this, I have made a python script that runs 4 
simulations at a time (using the multiprocessing module). However, each 
simulation takes about 60 seconds and my have 8 cores (Intel® Core™ 
i7-9700K CPU @ 3.60GHz × 8).  Is it not supposed to take approximately the 
same amount of because the processors are independent? Am I 

In order to isolate the problem I have executed deal.II's step 6 (with 12 
cycles and 1e5 maximum solver steps) 1, 2 and 4 times at the same (using 
different terminals).

1 running programs ~ 32 s user time 
2 running programs ~ 44 s user time 
4 running programs ~ 80 s user time 

Why the programs does not take the same time even though my computer have 8 
cores?
Any idea? Am I missing something obvious?

Ton Vidal

-- 
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/767ae142-a02d-4bc2-a454-d4c385d1b217%40googlegroups.com.


Re: [deal.II] Re: Problem installing Dealii-9.0.0

2020-02-11 Thread Bruno Turcksin
Le mar. 11 févr. 2020 à 09:03, Felipe Orellana <
felipeorellanarovir...@gmail.com> a écrit :

>
>   2)  I am not understanding well here:
>
> YW:  Why didn't you copy/paste the patch?
>
> What is 'the patch'  ..how can access that text?,
>
>   if I click on Tamiko's post, the web cannot find the site,
> cannot find the commit.
>
Here it is
https://github.com/dealii/dealii/commit/336319966b484889bbdd1da58623293b93980628.patch

Bruno

-- 
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/CAGVt9eOX1-9yk95exZ3BXj1vG1z8tEDLER1kw81p%3DwXOvpVdbw%40mail.gmail.com.


Re: [deal.II] Re: Problem installing Dealii-9.0.0

2020-02-11 Thread Felipe Orellana
 Hi Bruno,

  Thanks a lot for your response.

  1) YW: When you reconfigure deal.II, you should do it in a clean
directory or at least remove cmake's cache..

   Clearly, every time I recompile, I do it from a newly created build
directory.

  2)  I am not understanding well here:

YW:  Why didn't you copy/paste the patch?

What is 'the patch'  ..how can access that text?,

  if I click on Tamiko's post, the web cannot find the site, cannot
find the commit.

YW: Also you could just use CMake 3.15. This should fix your problem.

I do not have CMake 3.15..in my cluster, I installed 3.16 sometime ago.
For 3.15 I would need to install one from scratch.
I think this problem can be bypassed with 3.16 just by using the flags
correctly.. that's what i understand from the flag..

cheers many,
Felipe

On Tue, 11 Feb 2020 at 21:41, Bruno Turcksin 
wrote:

> Felipe,
>
> Le mar. 11 févr. 2020 à 08:29, Felipe Orellana <
> felipeorellanarovir...@gmail.com> a écrit :
>
>>
>> Hi Dan and Bruno,
>>
>>  I have followed the thread 9117 for solving this problem, by adding
>> the recommended flag:
>>
>> IF(${CMAKE_VERSION} VERSION_GREATER_EQUAL "3.16.0")
>>   LIST(TRANSFORM CMAKE_THREAD_LIBS_INIT PREPEND "-l")
>> ENDIF()
>>
> Why didn't you copy/paste the patch? Also you could just use CMake 3.15.
> This should fix your problem.
>
>>
>> But I have not succeeded in compiling. The errors posted are similar:
>>
>> -- Performing Test DEAL_II_HAVE_FLAG_Wplacement_new - Failed
>>
> That's not really a  problem. This test just checks if your compiler
> supports -Wplacement-new if it doesn't, we won't use the flag. So that test
> can fail safely.
>
> When you reconfigure deal.II, you should do it in a clean directory or at
> least remove cmake's cache.
>
> Best,
>
> Bruno
>
> --
> 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/CAGVt9eOC9WsZPR%3Dp5eTYcoCRP9eY0RCrbDQQivqQr%2BZX3MPM9Q%40mail.gmail.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/CABP9zGUCNCt1YPhAXzpx0NB%2BS43h1xrLnr%3DMuv6bhHW8LvJ-bA%40mail.gmail.com.


Re: [deal.II] Re: Problem installing Dealii-9.0.0

2020-02-11 Thread Bruno Turcksin
Felipe,

Le mar. 11 févr. 2020 à 08:29, Felipe Orellana <
felipeorellanarovir...@gmail.com> a écrit :

>
> Hi Dan and Bruno,
>
>  I have followed the thread 9117 for solving this problem, by adding
> the recommended flag:
>
> IF(${CMAKE_VERSION} VERSION_GREATER_EQUAL "3.16.0")
>   LIST(TRANSFORM CMAKE_THREAD_LIBS_INIT PREPEND "-l")
> ENDIF()
>
Why didn't you copy/paste the patch? Also you could just use CMake 3.15.
This should fix your problem.

>
> But I have not succeeded in compiling. The errors posted are similar:
>
> -- Performing Test DEAL_II_HAVE_FLAG_Wplacement_new - Failed
>
That's not really a  problem. This test just checks if your compiler
supports -Wplacement-new if it doesn't, we won't use the flag. So that test
can fail safely.

When you reconfigure deal.II, you should do it in a clean directory or at
least remove cmake's cache.

Best,

Bruno

-- 
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/CAGVt9eOC9WsZPR%3Dp5eTYcoCRP9eY0RCrbDQQivqQr%2BZX3MPM9Q%40mail.gmail.com.


Re: [deal.II] Re: Problem installing Dealii-9.0.0

2020-02-11 Thread Felipe Orellana
Hi Dan and Bruno,

 I have followed the thread 9117 for solving this problem, by adding
the recommended flag:

IF(${CMAKE_VERSION} VERSION_GREATER_EQUAL "3.16.0")
  LIST(TRANSFORM CMAKE_THREAD_LIBS_INIT PREPEND "-l")
ENDIF()

 which is what I understood from thread 9117 (which btw is not very well
written).

But I have not succeeded in compiling. The errors posted are similar:

-- Performing Test DEAL_II_HAVE_FLAG_Wplacement_new - Failed

 When reading the file 'configure_1_threads.cmake' I found inside my
directory dealii-9.0.0/cmake/configure
..
   I wonder where exactly I should add the corresponding
3-lines-instruction flag. I tried two target places inside the script, the
two that seemed to me as relevant and appropriate.. which are right below
the 'ADD FLAGS' locations..
 I attach the  virgin version of 'configure_1_threads.cmake'.

  what should I do?

  Am I interpreting thread 9117 correctly?
  Am I adding the flags where they should be?
  Is dealii 9.0.0 good for the purpose?

cheers,
Felipe


On Tue, 11 Feb 2020 at 11:37, Daniel Arndt  wrote:

> Felipe,
>
> The relevant error is at the end of the file:
>
> Linking CXX executable cmTC_9dc5e
> /usr/local/bin/cmake -E cmake_link_script
> CMakeFiles/cmTC_9dc5e.dir/link.txt --verbose=1
> /usr/bin/c++   -DDEAL_II_HAVE_USABLE_FLAGS_DEBUG -pedantic -fPIC -Wall
> -Wextra -Wpointer-arith -Wwrite-strings -Wsynth -Wsign-compare -Wswitch
> -Woverloaded-virtual -Wno-deprecated-declarations -Wno-literal-suffix
> -std=c++11 -Wno-parentheses -Wno-unused-local-typedefs -Og -ggdb
> -Wa,--compress-debug-sections-rdynamic
> CMakeFiles/cmTC_9dc5e.dir/src.cxx.o  -o cmTC_9dc5e  -rdynamic -fuse-ld=gold
> pthread -ggdb -lm -ldl /usr/lib64/libz.so -lrt
> c++: error: pthread: No such file or directory
>
> This is the issue described in
> https://github.com/dealii/dealii/issues/9116 and fixed in
> https://github.com/dealii/dealii/pull/9117.
>
> Best,
> Daniel
>
> Am Mo., 10. Feb. 2020 um 22:13 Uhr schrieb Felipe Orellana <
> felipeorellanarovir...@gmail.com>:
>
>>
>>   Hello Dan,
>>
>>Thanks for your attention.
>>
>> I attach the CMakeError.log
>>
>> The first error is: c++: error: unrecognized command line option
>> '-Wplacement-new'
>>
>>Maybe there is a chain sequence, so all sprouts from it..
>>
>> cheers many,
>>
>> Felipe
>>
>>
>>
>>
>> On Mon, 10 Feb 2020 at 23:41, Daniel Arndt 
>> wrote:
>>
>>>
>>> So this is a strange bug. The problem is from the flag
 -Woverloaded-virtual With gcc 4.8 and 4.9 As you can see the flag
 alone works https://wandbox.org/permlink/GLbCK7qVqfScXrZp but if I add
 another flag it won't compile
 https://wandbox.org/permlink/4Lw7aNqGlJkik6SL If you have access to
 gcc 5 or later, I would advise you to use that instead. You can also
 try the latest version of deal.II maybe we don't use that flag
 anymore.

>>>
>>> The problem here are the additional quotes in the compiler arguments,
>>> see https://godbolt.org/z/bwDjWy.
>>>
>>> Felipe, could you also send the file CMakeErrors.log?
>>>
>>> Best,
>>> Daniel
>>>
>>> --
>>> 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/CAOYDWb%2ByrLNsVfq7hcs%3D8inedF%2BoFhHYi9USJptYxE87Cv1P3g%40mail.gmail.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/CABP9zGWpOFJQP38ypMmdPYCqsRFbVGnS-d1-VD3phYBfgVz1yw%40mail.gmail.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