Re: [deal.II] Rotating turbine simulation in Deal ii
Hello Nitish, I wish to simulate a small scale high speed turbo-machine in deal.ii with FSI and simultaneously calculate Eigen frequencies. I would be glad to know if someone of you have done such a study and would be able to help me in this regard, I don't know. A good place to start may be by looking at the deal.ii publications list and the tutorials to see if there is something similar or adaptable there. Once you get started, ask some more specific questions related to your problem. Lots of kind people will try to help you out that point. :-) Best, Toby -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] CMake extra libraries?
Is there a cmake flag for specifying some extra libraries? Does: cmake -D extra_flags work? Best, Toby -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Re: Problem with postprocessor
I'm going to jump in with one of my random comments uninvited. Hopefully you don't mind. :-) I already run the example with uniform mesh, hence global refinement with 0 refinement cycles. The problem is, a specimen with 100 or 1000 elements is difficult to check due to the terminal output being flooded. I think what Thomas is kindly trying to point out is, that a single cell is a useless test case for almost all possible test cases that deal with practical problems. It seems your case is one of many examples. Try 16 cells. Look at the data and then try 32 cells and compare. Maybe write a procedure that will look at the data for you and put useful results into a file for you to look at? Can you plot results with gnuplot (for example)? Machines are stupid, they only can do what you tell them to do! So, why not reserve a day or so to calmly write the algorithms needed to extract the data you want in a way you can visualise? You need to do your analysis in some way. You can not expect a machine to do things for you. You have to instruct her what it is you want to be done. Write the code... :-) That is scientific computing. I could just output the result for one element, but then wheres the difference. Big difference in numerical analysis of this kind! ;-) I am not being unkind - though, maybe its time to get dirty, write some code, and look at the numbers, in order to figure out where the problem lies. If you can do that, there are alot of dealii users and developers that will help you out, and you'll get there in the end. :-) Best, Toby -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Call for Codes
Thanks David. Now I think I get it. :-) Best, Toby 20.04.2017 17:00 "David Wells" napisał(a): > Hi Toby, > > That sentence is not well written. I should have written > > I ocassionally scan GitHub to learn what features of deal.II people are > using in their own projects. > > For example, we will not break anyone's codes by removing the PETSc serial > vector classes: no one is using them anymore (though a few people still > include the headers). > > Thanks, > David Wells > > > On Thursday, April 20, 2017 at 10:32:52 AM UTC-4, Tobi Young wrote: >> >> >> I ocassionally scan GitHub to see if people are using features in deal.II >> outside of the library >> >> >> Please, clarify that statement for me. :-\ >> >> Best, Toby >> >> >> >> -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Call for Codes
I ocassionally scan GitHub to see if people are using features in deal.II outside of the library Please, clarify that statement for me. :-\ Best, Toby -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Re: Arbitrary mapping or Manifold?
Thank you Juan, for sharing your code. I am you have solved your problem. You've also partially solved (and reminded me of) a similar problem I was working on many years (where I failed). I will return to that problem in the near future and I will be implementing your solution to it. :-) Thanks. Best, Toby 07.04.2017 15:24 "Juan Carlos Araujo Cabarcas" napisał(a): > In the same spirit I would like to share a code that uses ChartManifold, > for generating a mapping of an ellipse applied to HyperBall. > > El miércoles, 5 de abril de 2017, 14:47:17 (UTC+2), Juan Carlos Araujo > Cabarcas escribió: >> >> Dear all, >> I recently found the thread: Something wrong with ChartManifold when >> chartdim=1: >> https://groups.google.com/forum/#!topic/dealii/Sfo9xKoeRpw >> a more straight answer to this thread. >> >> I took the liberty to copy David's code and modify it, so that the upper >> face of a square follows: y(x)=0.25*sin(PI*x) + 1. >> The function is not the same as I first proposed, but from this example >> it is pretty clear how to proceed. >> The result is plotted in the attached .png, along with a variation from >> step-10 in the deal.ii tutorial. >> >> I hope this may be of any use to somebody! >> >> Juan Carlos Araújo, >> Umeå Universitet >> El martes, 9 de febrero de 2016, 17:10:51 (UTC+1), Juan Carlos Araujo >> Cabarcas escribió: >>> >>> Dear all, >>> >>> I am working with the wave equation with variable refractive indexes >>> within the domain. >>> I receive meshes that come from a shape optimization routine, and my >>> task is to >>> run on arbitrarily curved elements resulting from the optimization. >>> Step-10 and others show how to use mappings and Manifolds to curve >>> elements following basic shapes like circles, cylinders etc. >>> >>> My guess is that it should be possible in deal.II to define my own >>> Manifolds based on how I want to bend my edges (optimization routine). >>> >>> I have prepared a very basic example on the matlab code attached that >>> has the info to plot the attached figure. There, the edges follow the >>> equation |x|^p + |y|^p=1, with p=6. >>> >>> It would be very illustrative to apply a mapping like what is done in >>> step-10 on a circle, but for the presented case. I would appreciate any >>> advise on how to achieve this, hopefully wth this example =) >>> >>> Thanks in advance! >>> >>> Juan Carlos Araújo-Cabarcas >>> Umeå Universitet. >>> >>> >>> -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Re: Arbitrary mapping or Manifold?
Thank you Juan, for sharing your code. I am you have solved your problem. You've also partially solved (and reminded me of) a similar problem I was working on many years (where I failed). I will return to that problem in the near future and I will be implementing your solution to it. :-) Thanks. Best, Toby 07.04.2017 15:24 "Juan Carlos Araujo Cabarcas" napisał(a): In the same spirit I would like to share a code that uses ChartManifold, for generating a mapping of an ellipse applied to HyperBall. El miércoles, 5 de abril de 2017, 14:47:17 (UTC+2), Juan Carlos Araujo Cabarcas escribió: > Dear all, > I recently found the thread: Something wrong with ChartManifold when > chartdim=1: > https://groups.google.com/forum/#!topic/dealii/Sfo9xKoeRpw > a more straight answer to this thread. > > I took the liberty to copy David's code and modify it, so that the upper > face of a square follows: y(x)=0.25*sin(PI*x) + 1. > The function is not the same as I first proposed, but from this example it > is pretty clear how to proceed. > The result is plotted in the attached .png, along with a variation from > step-10 in the deal.ii tutorial. > > I hope this may be of any use to somebody! > > Juan Carlos Araújo, > Umeå Universitet > El martes, 9 de febrero de 2016, 17:10:51 (UTC+1), Juan Carlos Araujo > Cabarcas escribió: > >> Dear all, >> >> I am working with the wave equation with variable refractive indexes >> within the domain. >> I receive meshes that come from a shape optimization routine, and my task >> is to >> run on arbitrarily curved elements resulting from the optimization. >> Step-10 and others show how to use mappings and Manifolds to curve >> elements following basic shapes like circles, cylinders etc. >> >> My guess is that it should be possible in deal.II to define my own >> Manifolds based on how I want to bend my edges (optimization routine). >> >> I have prepared a very basic example on the matlab code attached that has >> the info to plot the attached figure. There, the edges follow the equation >> |x|^p + |y|^p=1, with p=6. >> >> It would be very illustrative to apply a mapping like what is done in >> step-10 on a circle, but for the presented case. I would appreciate any >> advise on how to achieve this, hopefully wth this example =) >> >> Thanks in advance! >> >> Juan Carlos Araújo-Cabarcas >> Umeå Universitet. >> >> >> -- 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. For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Re: mpirun error when n_proc is not a factor of n_cells
Super great!
What was the problem and how did you fix it?
Best,
Toby
06.03.2017 19:21 "Nkosilathi Vundla" napisał(a):
> Hi Bruno
>
> That seems to have fixed the issue, glad I included the scoping.
>
> Thanks
> Nkosi
>
> On Monday, March 6, 2017 at 3:31:35 PM UTC+2, Bruno Turcksin wrote:
>>
>> Nkosi,
>>
>> it is hard to tell what is going on without seeing the code but you
>> probably don't want to do the compress in the for loop. compress needs to
>> be called by all the processors at the same time. This is not the case with
>> the code you show if the processors don't own the same number of cells.
>> What happens if you move residual.compress (VectorOperation::add); to
>> after the for loop?
>>
>> Best,
>>
>> Bruno
>>
>> On Monday, March 6, 2017 at 5:39:32 AM UTC-5, Nkosilathi Vundla wrote:
>>>
>>> Hi All
>>>
>>> I'm getting an error when I run my code. I get the following error when
>>> the number of cells is not a multiple of the number processors I run with
>>> (even if n_cells >> n_proc):
>>>
>>>
>>>
>>> An error occurred in line <216> of file <./unpack/deal.II-v8.4
>>> .1/source/lac/trilinos_vector_base.cc> in function
>>> void dealii::TrilinosWrappers::VectorBase::compress(dealii::Vecto
>>> rOperation::values)
>>> The violated condition was:
>>> result.max-result.min<1e-5
>>> The name and call sequence of the exception was:
>>> ExcMessage ("Not all processors agree whether the last operation on
>>> " "this vector was an addition or a set operation. This will " "prevent the
>>> compress() operation from succeeding.")
>>> Additional Information:
>>> Not all processors agree whether the last operation on this vector was
>>> an addition or a set operation. This will prevent the compress() operation
>>> from succeeding.
>>>
>>> Stacktrace:
>>> ---
>>> #0 /home/nkosi/deal.ii-candi/deal.II-v8.4.1/lib/libdeal_II.g.so.8.4.1:
>>> dealii::TrilinosWrappers::VectorBase::compress(dealii::Vecto
>>> rOperation::values)
>>> #1 ./oldroydb: fe_problem<2>::compute_residua
>>> l(dealii::TrilinosWrappers::MPI::Vector const&)
>>> #2 ./oldroydb: fe_problem<2>::run()
>>> #3 ./oldroydb: main
>>>
>>>
>>>
>>> The vector is question is used in the following way:
>>>
>>>
>>>
>>>
>>> TrilinosWrappers::MPI::Vector residual;
>>>
>>> setup system
>>> {
>>>
>>>
>>> dof_handler.distribute_dofs (fe_cg);
>>> locally_owned_dofs = dof_handler.locally_owned_dofs ();
>>>
>>>
>>>
>>> residual.reinit (locally_owned_dofs, mpi_communicator);
>>>
>>> ...
>>>
>>> }
>>>
>>> compute_residual
>>> {
>>> ...
>>>
>>> typename DoFHandler::active_cell_iterator cell =
>>> dof_handler.begin_active (), endc = dof_handler.end ();
>>> for (; cell != endc; ++cell)
>>> {
>>> if (cell->is_locally_owned ())
>>> {
>>> ..
>>>
>>> constraints.distribute_local_to_global (local_rhs,
>>> local_dof_indices,
>>> residual);
>>>
>>> for (unsigned int face_no = 0;
>>> face_no < GeometryInfo::faces_per_cell; ++face_no)
>>> {
>>> typename DoFHandler::face_iterator face = cell->face (
>>> face_no);
>>>
>>>
>>>
>>> residual[local_dof_indices[i]] -=ui_vi_vector (i);
>>> residual[dofs_neighbor[i]] -= ui_ve_vector (i);
>>>
>>>
>>>
>>> }
>>>
>>> ..
>>>
>>> residual.compress (VectorOperation::add);
>>>
>>> }
>>>
>>>
>>>
>>>
>>> I hope you will be able to help me find a way around this.
>>>
>>> Thanks
>>> Nkosi
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Re: mpirun error when n_proc is not a factor of n_cells
Hello Nkosi,
I have the feeling that you are not compressing distributed vectors.
You need to compress::VectorOperation::Add *on all processes* after
changing the vector state or passing to a LAC.
Can you figure out where in your code this is happening?
Best,
Toby
06.03.2017 14:31 "Bruno Turcksin" napisał(a):
> Nkosi,
>
> it is hard to tell what is going on without seeing the code but you
> probably don't want to do the compress in the for loop. compress needs to
> be called by all the processors at the same time. This is not the case with
> the code you show if the processors don't own the same number of cells.
> What happens if you move residual.compress (VectorOperation::add); to
> after the for loop?
>
> Best,
>
> Bruno
>
> On Monday, March 6, 2017 at 5:39:32 AM UTC-5, Nkosilathi Vundla wrote:
>>
>> Hi All
>>
>> I'm getting an error when I run my code. I get the following error when
>> the number of cells is not a multiple of the number processors I run with
>> (even if n_cells >> n_proc):
>>
>>
>>
>> An error occurred in line <216> of file <./unpack/deal.II-v8.4
>> .1/source/lac/trilinos_vector_base.cc> in function
>> void dealii::TrilinosWrappers::VectorBase::compress(dealii::Vecto
>> rOperation::values)
>> The violated condition was:
>> result.max-result.min<1e-5
>> The name and call sequence of the exception was:
>> ExcMessage ("Not all processors agree whether the last operation on "
>> "this vector was an addition or a set operation. This will " "prevent the
>> compress() operation from succeeding.")
>> Additional Information:
>> Not all processors agree whether the last operation on this vector was an
>> addition or a set operation. This will prevent the compress() operation
>> from succeeding.
>>
>> Stacktrace:
>> ---
>> #0 /home/nkosi/deal.ii-candi/deal.II-v8.4.1/lib/libdeal_II.g.so.8.4.1:
>> dealii::TrilinosWrappers::VectorBase::compress(dealii::Vecto
>> rOperation::values)
>> #1 ./oldroydb: fe_problem<2>::compute_residua
>> l(dealii::TrilinosWrappers::MPI::Vector const&)
>> #2 ./oldroydb: fe_problem<2>::run()
>> #3 ./oldroydb: main
>>
>>
>>
>> The vector is question is used in the following way:
>>
>>
>>
>>
>> TrilinosWrappers::MPI::Vector residual;
>>
>> setup system
>> {
>>
>>
>> dof_handler.distribute_dofs (fe_cg);
>> locally_owned_dofs = dof_handler.locally_owned_dofs ();
>>
>>
>>
>> residual.reinit (locally_owned_dofs, mpi_communicator);
>>
>> ...
>>
>> }
>>
>> compute_residual
>> {
>> ...
>>
>> typename DoFHandler::active_cell_iterator cell =
>> dof_handler.begin_active (), endc = dof_handler.end ();
>> for (; cell != endc; ++cell)
>> {
>> if (cell->is_locally_owned ())
>> {
>> ..
>>
>> constraints.distribute_local_to_global (local_rhs,
>> local_dof_indices,
>> residual);
>>
>> for (unsigned int face_no = 0;
>> face_no < GeometryInfo::faces_per_cell; ++face_no)
>> {
>> typename DoFHandler::face_iterator face = cell->face (
>> face_no);
>>
>>
>>
>> residual[local_dof_indices[i]] -=ui_vi_vector (i);
>> residual[dofs_neighbor[i]] -= ui_ve_vector (i);
>>
>>
>>
>> }
>>
>> ..
>>
>> residual.compress (VectorOperation::add);
>>
>> }
>>
>>
>>
>>
>> I hope you will be able to help me find a way around this.
>>
>> Thanks
>> Nkosi
>>
>>
>>
>>
>>
>>
>> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Re: internal compiler error: recipe for target 'source/numerics/CMakeFiles/obj_numerics.debug.dir/all
As JP says, this looks like a memory issue. Try allocating 4GB (or more). Best, Toby 19.12.2016 14:30 "Jean-Paul Pelteret" napisał(a): Dear ExcitingDDT, It may be possible that you've run out of system resources on the VM during compilation. How much RAM have you allocated to this VM image, and are you compiling with multiple threads? Regards, Jean-Paul On Monday, December 19, 2016 at 2:17:03 PM UTC+1, exciting...@gmail.com wrote: > > Hi, I'm a new learner for dealii. I have successfully installed dealii > package on my desktop, following the steps on the page > http://dealii.org/8.4.1/readme.html. However, I encountered an > compilation problem when I did the same steps on my vmware virtual machine > of my laptop. The Linux version on my vmware is Ubuntu 16.04 LTS, I have > prepare the additional softwares such as cmake, GNU make, Perl, doxygen, > GraphViz, GDB, ParaView. I extracted the tar.gz source package into a > directory, specified the installation destination directory for cmake, then > I type in this commands: > $ make install > > then it sucks at 22% of the progress. Here is the information on my > terminal: > > [ 19%] Built target obj_opencascade.debug > [ 19%] Generating data_out_dof_data.inst > [ 19%] Generating data_out_faces.inst > [ 19%] Generating data_out.inst > [ 19%] Generating data_out_rotation.inst > [ 20%] Generating data_out_stack.inst > [ 20%] Generating data_postprocessor.inst > [ 20%] Generating derivative_approximation.inst > [ 20%] Generating dof_output_operator.inst > [ 20%] Generating error_estimator_1d.inst > [ 20%] Generating error_estimator.inst > [ 20%] Generating fe_field_function.inst > [ 21%] Generating matrix_creator.inst > [ 21%] Generating matrix_tools.inst > [ 21%] Generating point_value_history.inst > [ 21%] Generating solution_transfer.inst > [ 21%] Generating time_dependent.inst > [ 21%] Generating vector_tools_boundary.inst > [ 21%] Generating vector_tools_constraints.inst > [ 22%] Generating vector_tools_integrate_difference.inst > [ 22%] Generating vector_tools_interpolate.inst > [ 22%] Generating vector_tools_mean_value.inst > [ 22%] Generating vector_tools_point_value.inst > [ 22%] Generating vector_tools_point_gradient.inst > [ 22%] Generating vector_tools_project.inst > [ 22%] Generating vector_tools_rhs.inst > [ 22%] Built target obj_numerics.inst > Scanning dependencies of target obj_numerics.debug > [ 22%] Building CXX object source/numerics/CMakeFiles/obj > _numerics.debug.dir/data_out.cc.o > c++: internal compiler error: Killed (program cc1plus) > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > source/numerics/CMakeFiles/obj_numerics.debug.dir/build.make:62: recipe > for target 'source/numerics/CMakeFiles/obj_numerics.debug.dir/data_out.cc.o' > failed > make[2]: *** [source/numerics/CMakeFiles/obj_numerics.debug.dir/data_out.cc.o] > Error 4 > CMakeFiles/Makefile2:1012: recipe for target > 'source/numerics/CMakeFiles/obj_numerics.debug.dir/all' > failed > make[1]: *** [source/numerics/CMakeFiles/obj_numerics.debug.dir/all] > Error 2 > Makefile:127: recipe for target 'all' failed > make: *** [all] Error 2 > > > Here is the configuration in CMAKE_BUILD_DIR/summary.log: > > ### > # > # deal.II configuration: > #CMAKE_BUILD_TYPE: DebugRelease > #BUILD_SHARED_LIBS: ON > #CMAKE_INSTALL_PREFIX: /home/jy/dealii/install-8.4.1 > #CMAKE_SOURCE_DIR: /home/jy/dealii/src-8.4.1/dealii-8.4.1 > #(version 8.4.1) > #CMAKE_BINARY_DIR: /home/jy/dealii/build-8.4.1 > #CMAKE_CXX_COMPILER: GNU 5.4.0 on platform Linux x86_64 > #/usr/bin/c++ > # > # Configured Features (DEAL_II_ALLOW_BUNDLED = ON, > DEAL_II_ALLOW_AUTODETECTION = ON): > # ( DEAL_II_WITH_64BIT_INDICES = OFF ) > # ( DEAL_II_WITH_ARPACK = OFF ) > #DEAL_II_WITH_BOOST set up with bundled packages > # ( DEAL_II_WITH_BZIP2 = OFF ) > #DEAL_II_WITH_CXX11 = ON > #DEAL_II_WITH_CXX14 = ON > # ( DEAL_II_WITH_HDF5 = OFF ) > # ( DEAL_II_WITH_LAPACK = OFF ) > # ( DEAL_II_WITH_METIS = OFF ) > # ( DEAL_II_WITH_MPI = OFF ) > #DEAL_II_WITH_MUPARSER set up with bundled packages > # ( DEAL_II_WITH_NETCDF = OFF ) > # ( DEAL_II_WITH_OPENCASCADE = OFF ) > # ( DEAL_II_WITH_P4EST = OFF ) > # ( DEAL_II_WITH_PETSC = OFF ) > # ( DEAL_II_WITH_SLEPC = OFF ) > #DEAL_II_WITH_THREADS set up with bundled packages > # ( DEAL_II_WITH_TRILINOS = OFF ) > # ( DEAL_II_WITH_UMFPACK = OFF ) > # ( DEAL_II_WITH_ZLIB = OFF ) > # > # Component configuration: > # ( DEAL_II_COMPONENT_DOCUMENTATION = OFF ) > #DEAL_II_COMPONENT_EXAMPLES > # ( DEAL_II_COMPONENT_PACKAGE = OFF ) > # ( DEAL_II_COMPONENT_PARAMETER_GUI = OFF ) > # > # Detailed information (compiler flags, feature configuration) can be > found in detailed.log >
Re: [deal.II] Re: Can we say that the higher order method, the more accurate?
To randomly add to this discussion... In general higher order polynomials are good for approximating smooth functions, such as the tail of an exponential decay. Interestingly, a denser grid with lower order polynomials sometimes works better for approximating a function that oscillates rapidly, such as the peak of a tightly packed sinosoidal wave. Think what would happen if you try to represent a zero valued function on one element. The order of the interpolation does not affect the accuracy its approximation! Then try to map an exponentially decaying function with increasing polynomial order and see what happens... That is a good exercise for a rainy day or a sunday afternoon. :-) Maybe try to approximate the functions, x, x^2, ..., x^n??? The result is, that if you want to save dofs, and your solution is mixed, hp-adaptivity is definately worth exploring - and it is alot of fun! That's my penny worth. :-) Best, Toby -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Step-42 -- Problem with Trilinos and P4EST
Ehsan. Yes, but that is not what you have done. ;-) Look at the configure script in your first email again calmly and *very carefully* and then look at my reply calmly and *very carefully*. In the configure script you sent us, you are missing a D on two lines, which I am guessing is stopping cmake from finding p4est and trilinos and is the reason you can not compile some of the tutorials. Have you checked the output from cmake or configure.log? Trust me, it works, but only if your syntax configuring deal.II is correct. :-) Best, Toby 2016-07-27 12:29 GMT+02:00 Ehsan : > Dear Toby, > > But in below links they are -DDEAL_II_With_... > > https://www.dealii.org/developer/readme.html > https://www.dealii.org/developer/external-libs/p4est.html > > Best, > Ehsan > > > > On Wednesday, July 27, 2016 at 12:19:07 PM UTC+2, Tobi Young wrote: >> >> Hello Eshan, >> >> Perhaps here is your error. It is a simple typo. ;-) >> >> > -DEAL_II_WITH_P4EST= ON >> > -DEAL_II_WITH_TRILINOS= ON >> >> Should be: >> >>-DDEAL_II_WITH_P4EST= ON >>-DDEAL_II_WITH_TRILINOS= ON >> >> Please check that the output (or configure.log) says it has found all >> of the libraries you were looking for and then recompile. >> Destroy CMakeCache before reconfiguring. >> >> I hope that helps you out. >> >> Best, >>Toby > > -- > 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. > For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Step-42 -- Problem with Trilinos and P4EST
Hello Eshan, Perhaps here is your error. It is a simple typo. ;-) > -DEAL_II_WITH_P4EST= ON > -DEAL_II_WITH_TRILINOS= ON Should be: -DDEAL_II_WITH_P4EST= ON -DDEAL_II_WITH_TRILINOS= ON Please check that the output (or configure.log) says it has found all of the libraries you were looking for and then recompile. Destroy CMakeCache before reconfiguring. I hope that helps you out. Best, Toby -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] SLEPc in Parallel Slower than Serial
> Using the Jacobi preconditioner the solution of a single eigenpair required > 17 minutes on 2 processors for a problem with 120,000 degrees of freedom. > The same eigenpair was calculated using the serial version of my code in 1.2 > minutes. There aren't any other preconditioners that are available for use > with SLEPc that I am aware of so for now I will just stick to the serial > version of my code. Don't lose hope and don't give up. Explore! :-) Best, Toby -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] SLEPc in Parallel Slower than Serial
Hi Jonathan, > I have tried the KrylovSchur and Lanczos solvers in both the parallel and > serial codes. The parallel code, when run with only one processor takes > roughly twice as long as with two processors (over 200 times slower than the > actual serial version). I have the serial version because I wanted to see if > it would be faster for "smaller" problems... It is. Much faster. Over 100 > times faster for the problems that I have "tested" it with (up to 180,000 > degrees of freedom, I have a small computer). This looks simple. Your parallel code is not doing what you think it is doing. I believe, that your application is faulty. This should not happen under normal circumstances, because the underlying objects of the parallel and serial PETSc objects are basically the same thing. > I am using a preconditioner because without it the parallel version of my > code does not converge (regardless of how many processors I run it on). This again tells me you have a bug in your parallel code. Why would you expect a problem to magically solve by changing the number of MPI processes? If your parallel version does not coverge with one MPI process, but it does in the serial version - you have a bug in the parallel version. You need to deal with that. :-) Do some debugging. Calm down and grab yourself a cup of tea or a pizza or some high sugar snacks, or whatever makes you happy and debug your code. I eat icecream when I debug, normally vanilla flavour. Check what happens with the memory on your machine when you run on multiple MPI processes. Are you calling a procedure that is eating up your memory when run in parallel? Is that why it is so slow? Do you have valgrind installed on your machine? If yes use it if o install it and then use it. Simplify your problem, simplify your solver, and check the residual-norm of your solution - it should be converging to something if all is ok. Do you get the same result when you run in parallel with fancy preconditioners and in serial with a simple KrylovSchur call? Another thing you can do is experiment with step-40? Do you experience the same behaviour, that parallel does not scale? SLEPc solvers are very good in parallel for large sparse eigenspectrum systems - and they use PETSc objects as their basis. Experiment with PETSc useage first. Sorry for my terseness, I am trying to help, but I am also rather busy these days. Best, Toby -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] SLEPc in Parallel Slower than Serial
Jonathan,
Interesting result. :-( It seems to me you are comparing apples to pears.
A few observations that make the situation very unclear for me. (i)
You are using two different solvers in two different ways. Your serial
code uses KrylovSchur and your parallel code uses Lanczos with some
kind of preconditioner. Why are you comparing these two solvers in
this way? (ii) Why do you have two different sets of code to solve the
same problem? The MPI code runs in serial as well.
Have you tried running your `parallel' code in serial (eg. mpirun -np
1 ./application)?
Why are you starting out with a preconditioner that you do not know is
useful to the problem? I do not know what your equation set is so it
is not possible for me comment on this.
I can tell you from experience, that in general SLEPc scales *very*
well with larger MPI processes - almost linearly if you do things
right - however, there is a caveat. SLEPc is designed for LARGE
problems and 4096 is a very small number of degrees of freedom. I do
not even bother to run such a problem in parallel except to check the
code returns the same result; such a small system is not useful for
benchmarking timings.
I suggest the following. Get rid of the serial code (parallel works in
serial too). Revert your `parallel' code to use the KrylovSchur solver
and don't use a preconditioner - that's the next step.
Refine your grid to, say one million degrees of freedom and compare
the timings for 1, 2, 4, etc. MPI processes. That is the first step to
bencharking, according to me. :-)
Then do the same with Lanczos and then try to preconditioner thing.
See how that works for you and then let me know what results you get.
One more thing to consider, is your K matrix sparse?
I hope that gives you a clue on finding out what the problem is.
Best,
Tobi
2016-06-10 17:30 GMT+02:00 Jonathan Russ :
> Hello -
>
> Does anyone have any experience with getting SLEPc to work efficiently in
> parallel? For some reason, SLEPc in parallel takes roughly 140 times more
> time to find one eigenvalue and eigenvector than the same solution in serial
> (i.e. the same matrices). For example, I have a problem with 4,905 degrees
> of freedom. It takes the serial solve (assembly and solution of one
> eigenpair) 0.16667 seconds, while the parallel solution (2 processors) takes
>> 24 seconds. For larger problems I haven't even decided to wait on the
> solution of the parallel problem to see how long it would actually take (the
> longest I waited was 45 minutes for a problem that took 1.2 minutes in
> serial).
>
> For the parallel solution I am using the AMG preconditioner but maybe this
> is a poor choice for this problem? I'm really not sure. The eigenvalue
> problem I am solving is:
> K x = w M x , where K is the elastic stiffness matrix, M is the mass matrix,
> w is an eigen-frequency of the system, and x is the eigenvector. Typically,
> the shift - invert method works very well (as it certainly does in serial)
> but I can't quite figure out why SLEPc is so helplessly slow in parallel. If
> anyone has any experience with this and would be willing to give me some
> advice, I would really appreciate it!
>
> Here is the parallel version of the "solve" function.
>
> unsigned int EigenvalueProblem::solve ()
> {
> TimerOutput::Scope t(computing_timer, "solve");
> pcout << " Number of eigenvectors requested: "
> << eigenvectors.size() << std::endl;
>
> PETScWrappers::PreconditionBoomerAMG::AdditionalData data;
> data.symmetric_operator = true;
> PETScWrappers::PreconditionBoomerAMG preconditioner(mpi_communicator,
> data);
> SolverControl
> linear_solver_control(dof_handler.n_dofs(),1.0e-12,false,false);
> PETScWrappers::SolverCG
> linear_solver(linear_solver_control,mpi_communicator);
> linear_solver.initialize(preconditioner);
>
> SolverControl solver_control (2000, 1e-9, false, false);
> SLEPcWrappers::SolverLanczos eigensolver(solver_control,
> mpi_communicator);
>
> double shift_freq = parameters.get_double ("Shift frequency");
> double eigen_shift = std::pow( 2.0 * PI * shift_freq, 2.0);
> SLEPcWrappers::TransformationShiftInvert::AdditionalData
> additional_data(eigen_shift);
> SLEPcWrappers::TransformationShiftInvert shift (mpi_communicator,
> additional_data);
> shift.set_solver(linear_solver);
> eigensolver.set_transformation (shift);
> eigensolver.set_which_eigenpairs (EPS_SMALLEST_REAL);
> eigensolver.set_problem_type (EPS_GHEP);
>
> eigensolver.solve
> (stiffness_matrix,mass_matrix,eigenvalues,eigenvectors,
>eigenvectors.size());
>
> for (unsigned int i=0; i eigenvectors[i] /= eigenvectors[i].linfty_norm ();
>
> // Finally return the number of iterations it took to converge:
> return solver_control.last_step ();
> }
>
> And here is the serial version of the solve function:
> unsigned int EigenvalueProblem::solve ()
> {
>
> st
Re: [deal.II] Error during P4EST installation
This happens when your fortan compiler is not useable. Try to install gfortran on your machine and see if the problem goes away. Best, Toby 2016-05-18 17:29 GMT+02:00 ehsan esfahani : > Hello, > > I am trying to install a package (P4EST) along with > D > eal ii library > . > I got an error telling me that " Fortran 77 cannot create executables". My > operation system is REDHAT LINUX and I find out package > gcc-gfortran-4.8.5-4.el7.x86_64 already installed on my computer. I'm a > beginner at redhat and dealii as well. > > Thanks in advance for your help, > > -- > 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. > For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
