date:20210824

[deal.II] Re: shift-invert transformation problem with slepc

2021-08-24 Thread Anton Ermakov

Ok, I see - it is that EPS_TARGET_MAGNITUDE flag that was missing. It works 
now! Thanks a lot, Simon.
Anton.

On Tuesday, August 24, 2021 at 12:14:20 AM UTC-6 simon...@gmail.com wrote:

> Hi,
>
> I think you need to set both which eigen pair and the target value. For 
> example, if you look for the eigenvalue closest in magnitude to 0, you need 
> to set the following
>
> const double target_eigenvalue = 0;
> eigensolver.set_which_eigenpairs(EPS_TARGET_MAGNITUDE);
> eigensolver.set_target_eigenvalue(target_eigenvalue);
>
> Depending on slepc version it might be that you can only choose 
> EPS_TARGET_MAGNITUDE. See question 8 here:
>
> https://slepc.upv.es/documentation/faq.htm
>
> Best,
> Simon
>
> On Tuesday, August 24, 2021 at 3:39:29 AM UTC+2 anton.i...@gmail.com 
> wrote:
>
>> Dear All,
>>
>> I am trying to use a shift-invert transformation in step-36. I did 
>> minimal changes in the solve function adding the following code that 
>> describes what spectral transformation I need to do:
>>
>> SolverControl solver_control (dof_handler.n_dofs(), 1e-9);
>> SLEPcWrappers::SolverKrylovSchur eigensolver(solver_control);
>> eigensolver.set_which_eigenpairs (EPS_SMALLEST_REAL);
>> eigensolver.set_problem_type (EPS_GHEP);
>>
>> double eigen_shift = 1.0e-4;
>> SLEPcWrappers::TransformationShiftInvert::AdditionalData 
>> additional_data(eigen_shift);
>> SLEPcWrappers::TransformationShiftInvert shift (MPI_COMM_WORLD, 
>> additional_data);
>> eigensolver.set_transformation (shift);
>>
>> eigensolver.solve(stiffness_matrix,
>>   mass_matrix,
>>   eigenvalues,
>>   eigenfunctions,
>>   eigenfunctions.size());
>>
>> and it gives me the following error: 
>>
>> [0]PETSC ERROR: Shift-and-invert requires a target 'which' (see 
>> EPSSetWhichEigenpairs), for instance -st_type sinvert -eps_target 0 
>> -eps_target_magnitude
>>
>> Any help to resolve this error is greatly appreciated. I also attached 
>> the full code of modified step-36.
>>
>> Thank you,
>> Anton.
>>
>

-- 
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/879b9d55-f2ae-456f-828b-91bb26b6ba20n%40googlegroups.com.

[deal.II] deal.II Newsletter #179

2021-08-24 Thread 'Rene Gassmoeller' via deal.II User Group

Hello everyone!

This is deal.II newsletter #179.
It automatically reports recently merged features and discussions about the 
deal.II finite element library.


## Below you find a list of recently proposed or merged features:

#12703: Require GINKGO 1.4.0 (proposed by gfcas) 
https://github.com/dealii/dealii/pull/12703

#12702: Fix HangingNodes::setup_constraints() for multiple components (proposed 
by peterrum) https://github.com/dealii/dealii/pull/12702

#12700: Fix typename number (proposed by gfcas; merged) 
https://github.com/dealii/dealii/pull/12700

#12699: Enhance VectorTools::project (proposed by gfcas) 
https://github.com/dealii/dealii/pull/12699

#12698: AssertDimension macro in examples (proposed by gfcas; merged) 
https://github.com/dealii/dealii/pull/12698

#12697: Add tolerance to subdivided_cylinder generator (proposed by blaisb; 
merged) https://github.com/dealii/dealii/pull/12697

#12696: Extend MGTwoLevelTransfer::reinit_polynomial_transfer() so that it 
works on any refinement level without HN (proposed by peterrum; merged) 
https://github.com/dealii/dealii/pull/12696

#12695: Do not store unnecessary variables. (proposed by bangerth; merged) 
https://github.com/dealii/dealii/pull/12695

#12694: Make sure that copying exceptions doesn't imply dropping the backtrace. 
(proposed by bangerth; merged) https://github.com/dealii/dealii/pull/12694

#12692: Add Tensor::to_array(). (proposed by drwells) 
https://github.com/dealii/dealii/pull/12692

#12691: Deprecate ArrayView functionality for tensors. (proposed by bangerth) 
https://github.com/dealii/dealii/pull/12691

#12690: Implement multiway DoF identities on vertices/lines/quads. (proposed by 
bangerth) https://github.com/dealii/dealii/pull/12690

#12688: Unify spelling 2. (proposed by marcfehling; merged) 
https://github.com/dealii/dealii/pull/12688

#12687: Sort member functions in .cc file. (proposed by bangerth; merged) 
https://github.com/dealii/dealii/pull/12687

#12685: Avoid the use of ArrayView for Tensors in MPI::sum(). (proposed by 
bangerth; merged) https://github.com/dealii/dealii/pull/12685

#12684: Introduce ParticleAccessor::set_properties() taking a Tensor. (proposed 
by bangerth) https://github.com/dealii/dealii/pull/12684

#12683: Unify spelling. (proposed by bangerth; merged) 
https://github.com/dealii/dealii/pull/12683

#12682: Group member functions in hp::FECollection for doxygen. (proposed by 
bangerth; merged) https://github.com/dealii/dealii/pull/12682

#12681: Allow for the default construction of 1d face iterators. (proposed by 
bangerth; merged) https://github.com/dealii/dealii/pull/12681

#12680: Prevent excess timer output. (proposed by marcfehling; merged) 
https://github.com/dealii/dealii/pull/12680

#12678: Typo fix in step-38 intro.dox (proposed by amartinhuertas; merged) 
https://github.com/dealii/dealii/pull/12678

#12677: tria.cc: Make exception and comment easier to read (proposed by 
kronbichler; merged) https://github.com/dealii/dealii/pull/12677

#12676: Remove special treatment of boundary cells (proposed by peterrum; 
merged) https://github.com/dealii/dealii/pull/12676

#12675: Avoid serializing lines on TriaFaces twice. (proposed by marcfehling; 
merged) https://github.com/dealii/dealii/pull/12675

#12674: Make TriaAccessor::set_*_boundary() const. (proposed by bangerth; 
merged) https://github.com/dealii/dealii/pull/12674

#12673: Remove an unused member variable. (proposed by drwells; merged) 
https://github.com/dealii/dealii/pull/12673

#12672: Use Mapping::get_vertices(). (proposed by drwells; merged) 
https://github.com/dealii/dealii/pull/12672

#12671: Mark some things as protected. (proposed by drwells; merged) 
https://github.com/dealii/dealii/pull/12671

#12670: Avoid copying some Quadrature rules in FESystem. (proposed by drwells; 
merged) https://github.com/dealii/dealii/pull/12670

#12669: Fix p:f:T for manifolds (proposed by peterrum) 
https://github.com/dealii/dealii/pull/12669

#12667: Fix documentation (proposed by zjiaqi2018; merged) 
https://github.com/dealii/dealii/pull/12667

#12666: Fix compilation with GCC 5.4. (proposed by drwells; merged) 
https://github.com/dealii/dealii/pull/12666

#12664: Unghost matrix diagonals (proposed by drwells) 
https://github.com/dealii/dealii/pull/12664

#12661: Update documentation of FE_Q constructor. (proposed by bangerth; 
merged) https://github.com/dealii/dealii/pull/12661

#12634: Fix MGTransferMatrixFree plain_copy bug (proposed by tjhei; merged) 
https://github.com/dealii/dealii/pull/12634

#12609: Fix AlignedVector memory management after 
replicate_across_communicator() (proposed by bangerth; merged) 
https://github.com/dealii/dealii/pull/12609

#12601: Deprecated autopartition parameter in 
parallel::DistributedTriangulationBase::load() (proposed by marcfehling; 
merged) https://github.com/dealii/dealii/pull/12601

#12546: fix: Updated dotgdbinit to work with version 9.3 (proposed by TLJB; 
merged)

Re: [deal.II] point_value, Real parts, step-29

2021-08-24 Thread 'peterrum' via deal.II User Group

You need to pass a vector of points.

PM

On Tuesday, 24 August 2021 at 15:26:05 UTC+2 hermes...@gmail.com wrote:

> Thank you.
>
> Doing something similar:
>
>   *const* MappingQ1 mapping;
>
>   Utilities::MPI::RemotePointEvaluation evaluation_cache;
>
>   VectorTools::point_values(mapping, dof_handler, 
> locally_relevant_solution, Point<2>(0.2, 0.2), evaluation_cache);
>
>
> I get the following error:
>
>  error: no matching function for call to 'point_values'
>
>   VectorTools::point_values(mapping, dof_handler, 
> locally_relevant_solution, Point<2>(0.2, 0.2), evaluation_cache);
>
>
>
> I checked the parameters and seems to be ok. What can be producing the 
> error?
>
> Thank you again
>
> H  
>
> El mar, 24 ago 2021 a las 14:59, 'peterrum' via deal.II User Group (<
> dea...@googlegroups.com>) escribió:
>
>> Hi Hermes,
>>
>> You don't need to do anything regarding the setup (it is done within the 
>> function). Just take at a look at: 
>> https://github.com/dealii/dealii/blob/44b6aadb35aca2333e4bfb6c9ce29c613f4dc9e9/tests/remote_point_evaluation/vector_tools_evaluate_at_points_01.cc#L214-L216
>>
>> I'll extend the documentation with an example today or tomorrow!
>>
>> Hope that helps,
>> PM
>>
>> On Tuesday, 24 August 2021 at 14:46:46 UTC+2 hermes...@gmail.com wrote:
>>
>>> Thank you for pointing that function.
>>>
>>> I am having some problems when creating the mapping and I am not sure if 
>>> the function call is right. Could you please help me with that? 
>>>
>>>   std::vector<*double*> pointSol;
>>>
>>>   Mapping mapping;
>>>
>>>   
>>>
>>>   dealii::Utilities::MPI::RemotePointEvaluation remotePoint;
>>>
>>>   remotePoint.reinit();
>>>
>>>   pointSol = VectorTools::point_values(mapping, 
>>> dof_handler,locally_relevant_solution,Point<2>(0.2, 0.2),remotePoint);
>>>
>>>
>>>
>>> Thank you
>>>
>>> H
>>>
>>>   
>>>
>>> El mar, 24 ago 2021 a las 14:12, Martin Kronbichler (<
>>> kronbichl...@gmail.com>) escribió:
>>>
 Dear Hermes,

 Did you try VectorTools::point_values, 
 https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#a1ad6eceb6cbeaa505baf7f938289bbde
  
 ?

 As an alternative, you can also check if the point is in the locally 
 owned cell of the respective cell, and run the evaluation only on that MPI 
 rank. You can then use an MPI collective, like MPI_Bcast or deal.II's 
 version Utilities::MPI::broadcast, to get the solution to all MPI ranks 
 (typically with another collective to make all ranks agree on who sends 
 the 
 information).

 Best,
 Martin

 This is a variant that allows the evaluation even on remote processes.
 On 24.08.21 14:05, Hermes Sampedro wrote:

 Dear all,  

 I am trying to extend my implementation with parallel computing. I 
 would like to get the solution in a single point when having a distributed 
 system. For example, in step-40 I have the *locally_relevant_solution* at 
 the output_result(...) function.
 In a non distributed implementation I used:

   Vector<*double*> vecSol (fe.n_components());

   VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 
 0.2),vecSol);


 What is the easiest way to do that? Is it possible to check if the 
 point is inside the *locally_relevant_solution? *Or would be more 
 appropriate to create a copy of the solution in a global vector and get 
 the 
 point from there?


 Thank you

 H

 El mié, 11 ago 2021 a las 10:12, Hermes Sampedro () 
 escribió:

> Thank you very much, I could make it work. 
>
> Regards, 
> Hermes
>
> El mar, 10 ago 2021 a las 19:46, Jean-Paul Pelteret (<
> jppel...@gmail.com>) escribió:
>
>> Another thing: You probably also need to initialise with the right 
>> number of components. So something like 
>> Vector vecSol (fe.n_components());
>>
>>
>> On 10. Aug 2021, at 19:40, Jean-Paul Pelteret  
>> wrote:
>>
>> Hi Hermes, 
>>
>> You don’t say what errors you’re seeing, but my guess is that it now 
>> doesn’t compile. This variant of the function (the one that Daniel 
>> linked 
>> to) returns void, so you should call it before outputting the result:
>>
>> Vector vecSol;
>> VectorTools::point_value(dof_handler, 
>> solution,Point<2>(0.2, 0.2),vecSol)
>> std::cout << "Solution at (0.2,0.2): "<< vecSol << std::endl;
>>
>> This will hopefully get you what you want.
>>
>> Best,
>> Jean-Paul
>>
>>
>> On 10. Aug 2021, at 16:09, Hermes Sampedro  
>> wrote:
>>
>> Thank you for your answer. I am not sure if I fully understand your 
>> suggestion. Do you mean something like that: 
>>
>>  Vector<*double*> vecSol;
>>  std::cout << "Solution at (0.2,0.2): "<< 
>>

Re: [deal.II] point_value, Real parts, step-29

2021-08-24 Thread Hermes Sampedro

Thank you.

Doing something similar:

  *const* MappingQ1 mapping;

  Utilities::MPI::RemotePointEvaluation evaluation_cache;

  VectorTools::point_values(mapping, dof_handler,
locally_relevant_solution, Point<2>(0.2, 0.2), evaluation_cache);


I get the following error:

 error: no matching function for call to 'point_values'

  VectorTools::point_values(mapping, dof_handler,
locally_relevant_solution, Point<2>(0.2, 0.2), evaluation_cache);



I checked the parameters and seems to be ok. What can be producing the
error?

Thank you again

H

El mar, 24 ago 2021 a las 14:59, 'peterrum' via deal.II User Group (<
dealii@googlegroups.com>) escribió:

> Hi Hermes,
>
> You don't need to do anything regarding the setup (it is done within the
> function). Just take at a look at:
> https://github.com/dealii/dealii/blob/44b6aadb35aca2333e4bfb6c9ce29c613f4dc9e9/tests/remote_point_evaluation/vector_tools_evaluate_at_points_01.cc#L214-L216
>
> I'll extend the documentation with an example today or tomorrow!
>
> Hope that helps,
> PM
>
> On Tuesday, 24 August 2021 at 14:46:46 UTC+2 hermes...@gmail.com wrote:
>
>> Thank you for pointing that function.
>>
>> I am having some problems when creating the mapping and I am not sure if
>> the function call is right. Could you please help me with that?
>>
>>   std::vector<*double*> pointSol;
>>
>>   Mapping mapping;
>>
>>
>>
>>   dealii::Utilities::MPI::RemotePointEvaluation remotePoint;
>>
>>   remotePoint.reinit();
>>
>>   pointSol = VectorTools::point_values(mapping,
>> dof_handler,locally_relevant_solution,Point<2>(0.2, 0.2),remotePoint);
>>
>>
>>
>> Thank you
>>
>> H
>>
>>
>>
>> El mar, 24 ago 2021 a las 14:12, Martin Kronbichler (<
>> kronbichl...@gmail.com>) escribió:
>>
>>> Dear Hermes,
>>>
>>> Did you try VectorTools::point_values,
>>> https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#a1ad6eceb6cbeaa505baf7f938289bbde
>>> ?
>>>
>>> As an alternative, you can also check if the point is in the locally
>>> owned cell of the respective cell, and run the evaluation only on that MPI
>>> rank. You can then use an MPI collective, like MPI_Bcast or deal.II's
>>> version Utilities::MPI::broadcast, to get the solution to all MPI ranks
>>> (typically with another collective to make all ranks agree on who sends the
>>> information).
>>>
>>> Best,
>>> Martin
>>>
>>> This is a variant that allows the evaluation even on remote processes.
>>> On 24.08.21 14:05, Hermes Sampedro wrote:
>>>
>>> Dear all,
>>>
>>> I am trying to extend my implementation with parallel computing. I would
>>> like to get the solution in a single point when having a distributed
>>> system. For example, in step-40 I have the *locally_relevant_solution* at
>>> the output_result(...) function.
>>> In a non distributed implementation I used:
>>>
>>>   Vector<*double*> vecSol (fe.n_components());
>>>
>>>   VectorTools::point_value(dof_handler, solution,Point<2>(0.2,
>>> 0.2),vecSol);
>>>
>>>
>>> What is the easiest way to do that? Is it possible to check if the point
>>> is inside the *locally_relevant_solution? *Or would be more appropriate
>>> to create a copy of the solution in a global vector and get the point from
>>> there?
>>>
>>>
>>> Thank you
>>>
>>> H
>>>
>>> El mié, 11 ago 2021 a las 10:12, Hermes Sampedro ()
>>> escribió:
>>>
 Thank you very much, I could make it work.

 Regards,
 Hermes

 El mar, 10 ago 2021 a las 19:46, Jean-Paul Pelteret (<
 jppel...@gmail.com>) escribió:

> Another thing: You probably also need to initialise with the right
> number of components. So something like
> Vector vecSol (fe.n_components());
>
>
> On 10. Aug 2021, at 19:40, Jean-Paul Pelteret 
> wrote:
>
> Hi Hermes,
>
> You don’t say what errors you’re seeing, but my guess is that it now
> doesn’t compile. This variant of the function (the one that Daniel linked
> to) returns void, so you should call it before outputting the result:
>
> Vector vecSol;
> VectorTools::point_value(dof_handler,
> solution,Point<2>(0.2, 0.2),vecSol)
> std::cout << "Solution at (0.2,0.2): "<< vecSol << std::endl;
>
> This will hopefully get you what you want.
>
> Best,
> Jean-Paul
>
>
> On 10. Aug 2021, at 16:09, Hermes Sampedro 
> wrote:
>
> Thank you for your answer. I am not sure if I fully understand your
> suggestion. Do you mean something like that:
>
>  Vector<*double*> vecSol;
>  std::cout << "Solution at (0.2,0.2): "<<
> VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 
> 0.2),vecSol)<<
> std::endl;
>
>
> I still get some errors. Is there not any way to get for example the
> real part of *solution* easily and use it directly on the point_value
> as in step-3?
>
> Thank you
> H
>
> El mar, 10 ago 2021 a las 15:49, Daniel Arndt ()
> escribió:

Re: [deal.II] point_value, Real parts, step-29

2021-08-24 Thread 'peterrum' via deal.II User Group

Hi Hermes,

You don't need to do anything regarding the setup (it is done within the 
function). Just take at a look 
at: 
https://github.com/dealii/dealii/blob/44b6aadb35aca2333e4bfb6c9ce29c613f4dc9e9/tests/remote_point_evaluation/vector_tools_evaluate_at_points_01.cc#L214-L216

I'll extend the documentation with an example today or tomorrow!

Hope that helps,
PM

On Tuesday, 24 August 2021 at 14:46:46 UTC+2 hermes...@gmail.com wrote:

> Thank you for pointing that function.
>
> I am having some problems when creating the mapping and I am not sure if 
> the function call is right. Could you please help me with that? 
>
>   std::vector<*double*> pointSol;
>
>   Mapping mapping;
>
>   
>
>   dealii::Utilities::MPI::RemotePointEvaluation remotePoint;
>
>   remotePoint.reinit();
>
>   pointSol = VectorTools::point_values(mapping, 
> dof_handler,locally_relevant_solution,Point<2>(0.2, 0.2),remotePoint);
>
>
>
> Thank you
>
> H
>
>   
>
> El mar, 24 ago 2021 a las 14:12, Martin Kronbichler (<
> kronbichl...@gmail.com>) escribió:
>
>> Dear Hermes,
>>
>> Did you try VectorTools::point_values, 
>> https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#a1ad6eceb6cbeaa505baf7f938289bbde
>>  
>> ?
>>
>> As an alternative, you can also check if the point is in the locally 
>> owned cell of the respective cell, and run the evaluation only on that MPI 
>> rank. You can then use an MPI collective, like MPI_Bcast or deal.II's 
>> version Utilities::MPI::broadcast, to get the solution to all MPI ranks 
>> (typically with another collective to make all ranks agree on who sends the 
>> information).
>>
>> Best,
>> Martin
>>
>> This is a variant that allows the evaluation even on remote processes.
>> On 24.08.21 14:05, Hermes Sampedro wrote:
>>
>> Dear all,  
>>
>> I am trying to extend my implementation with parallel computing. I would 
>> like to get the solution in a single point when having a distributed 
>> system. For example, in step-40 I have the *locally_relevant_solution* at 
>> the output_result(...) function.
>> In a non distributed implementation I used:
>>
>>   Vector<*double*> vecSol (fe.n_components());
>>
>>   VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 
>> 0.2),vecSol);
>>
>>
>> What is the easiest way to do that? Is it possible to check if the point 
>> is inside the *locally_relevant_solution? *Or would be more appropriate 
>> to create a copy of the solution in a global vector and get the point from 
>> there?
>>
>>
>> Thank you
>>
>> H
>>
>> El mié, 11 ago 2021 a las 10:12, Hermes Sampedro () 
>> escribió:
>>
>>> Thank you very much, I could make it work. 
>>>
>>> Regards, 
>>> Hermes
>>>
>>> El mar, 10 ago 2021 a las 19:46, Jean-Paul Pelteret () 
>>> escribió:
>>>
 Another thing: You probably also need to initialise with the right 
 number of components. So something like 
 Vector vecSol (fe.n_components());


 On 10. Aug 2021, at 19:40, Jean-Paul Pelteret  
 wrote:

 Hi Hermes, 

 You don’t say what errors you’re seeing, but my guess is that it now 
 doesn’t compile. This variant of the function (the one that Daniel linked 
 to) returns void, so you should call it before outputting the result:

 Vector vecSol;
 VectorTools::point_value(dof_handler, 
 solution,Point<2>(0.2, 0.2),vecSol)
 std::cout << "Solution at (0.2,0.2): "<< vecSol << std::endl;

 This will hopefully get you what you want.

 Best,
 Jean-Paul


 On 10. Aug 2021, at 16:09, Hermes Sampedro  wrote:

 Thank you for your answer. I am not sure if I fully understand your 
 suggestion. Do you mean something like that: 

  Vector<*double*> vecSol;
  std::cout << "Solution at (0.2,0.2): "<< 
 VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 
 0.2),vecSol)<< 
 std::endl;


 I still get some errors. Is there not any way to get for example the 
 real part of *solution* easily and use it directly on the point_value 
 as in step-3?

 Thank you 
 H

 El mar, 10 ago 2021 a las 15:49, Daniel Arndt () 
 escribió:

> Hermes,
>
> Use another overload. The one returning the solution as a parameter 
> should work: 
> https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#acd358e9b110ccbf4a7f76796d206b9c7
>
> Best,
> Daniel
>
> Am Di., 10. Aug. 2021 um 09:41 Uhr schrieb Hermes Sampedro <
> hermes...@gmail.com>:
>
>> Dear all,  
>>
>> It is explained in Step-3 how to evaluate the solution in a point. I 
>> am trying to do the same for Step-29, to evaluate the real and imaginary 
>> parts separately in a single point:
>>
>> *std::cout << "Solution at (0.2,0.2): "<< 
>> VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2))<< 
>> std::endl;*
>>
>> I do not have

Re: [deal.II] point_value, Real parts, step-29

2021-08-24 Thread Hermes Sampedro

Thank you for pointing that function.

I am having some problems when creating the mapping and I am not sure if
the function call is right. Could you please help me with that?

  std::vector<*double*> pointSol;

  Mapping mapping;



  dealii::Utilities::MPI::RemotePointEvaluation remotePoint;

  remotePoint.reinit();

  pointSol = VectorTools::point_values(mapping,
dof_handler,locally_relevant_solution,Point<2>(0.2, 0.2),remotePoint);



Thank you

H



El mar, 24 ago 2021 a las 14:12, Martin Kronbichler (<
kronbichler.mar...@gmail.com>) escribió:

> Dear Hermes,
>
> Did you try VectorTools::point_values,
> https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#a1ad6eceb6cbeaa505baf7f938289bbde
> ?
>
> As an alternative, you can also check if the point is in the locally owned
> cell of the respective cell, and run the evaluation only on that MPI rank.
> You can then use an MPI collective, like MPI_Bcast or deal.II's version
> Utilities::MPI::broadcast, to get the solution to all MPI ranks (typically
> with another collective to make all ranks agree on who sends the
> information).
>
> Best,
> Martin
>
> This is a variant that allows the evaluation even on remote processes.
> On 24.08.21 14:05, Hermes Sampedro wrote:
>
> Dear all,
>
> I am trying to extend my implementation with parallel computing. I would
> like to get the solution in a single point when having a distributed
> system. For example, in step-40 I have the *locally_relevant_solution* at
> the output_result(...) function.
> In a non distributed implementation I used:
>
>   Vector<*double*> vecSol (fe.n_components());
>
>   VectorTools::point_value(dof_handler, solution,Point<2>(0.2,
> 0.2),vecSol);
>
>
> What is the easiest way to do that? Is it possible to check if the point
> is inside the *locally_relevant_solution? *Or would be more appropriate
> to create a copy of the solution in a global vector and get the point from
> there?
>
>
> Thank you
>
> H
>
> El mié, 11 ago 2021 a las 10:12, Hermes Sampedro ()
> escribió:
>
>> Thank you very much, I could make it work.
>>
>> Regards,
>> Hermes
>>
>> El mar, 10 ago 2021 a las 19:46, Jean-Paul Pelteret (<
>> jppelte...@gmail.com>) escribió:
>>
>>> Another thing: You probably also need to initialise with the right
>>> number of components. So something like
>>> Vector vecSol (fe.n_components());
>>>
>>>
>>> On 10. Aug 2021, at 19:40, Jean-Paul Pelteret 
>>> wrote:
>>>
>>> Hi Hermes,
>>>
>>> You don’t say what errors you’re seeing, but my guess is that it now
>>> doesn’t compile. This variant of the function (the one that Daniel linked
>>> to) returns void, so you should call it before outputting the result:
>>>
>>> Vector vecSol;
>>> VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2),vecSol)
>>> std::cout << "Solution at (0.2,0.2): "<< vecSol << std::endl;
>>>
>>> This will hopefully get you what you want.
>>>
>>> Best,
>>> Jean-Paul
>>>
>>>
>>> On 10. Aug 2021, at 16:09, Hermes Sampedro 
>>> wrote:
>>>
>>> Thank you for your answer. I am not sure if I fully understand your
>>> suggestion. Do you mean something like that:
>>>
>>>  Vector<*double*> vecSol;
>>>  std::cout << "Solution at (0.2,0.2): "<<
>>> VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2),vecSol)<<
>>> std::endl;
>>>
>>>
>>> I still get some errors. Is there not any way to get for example the
>>> real part of *solution* easily and use it directly on the point_value
>>> as in step-3?
>>>
>>> Thank you
>>> H
>>>
>>> El mar, 10 ago 2021 a las 15:49, Daniel Arndt ()
>>> escribió:
>>>
 Hermes,

 Use another overload. The one returning the solution as a parameter
 should work:
 https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#acd358e9b110ccbf4a7f76796d206b9c7

 Best,
 Daniel

 Am Di., 10. Aug. 2021 um 09:41 Uhr schrieb Hermes Sampedro <
 hermesampe...@gmail.com>:

> Dear all,
>
> It is explained in Step-3 how to evaluate the solution in a point. I
> am trying to do the same for Step-29, to evaluate the real and imaginary
> parts separately in a single point:
>
> *std::cout << "Solution at (0.2,0.2): "<<
> VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2))<<
> std::endl;*
>
> I do not have any problems compiling however, an error occurs when
> running:
>
> *The violated condition was:  dof.get_fe(0).n_components() == 1*
>
> What is the proper way to call the real and imaginary parts of the
> solution at a particular point here?
>
>
> Thank you very much!
>
> H.
>
> --
> 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

Re: [deal.II] point_value, Real parts, step-29

2021-08-24 Thread Martin Kronbichler


Dear Hermes,

Did you try VectorTools::point_values, 
https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#a1ad6eceb6cbeaa505baf7f938289bbde 
?


As an alternative, you can also check if the point is in the locally 
owned cell of the respective cell, and run the evaluation only on that 
MPI rank. You can then use an MPI collective, like MPI_Bcast or 
deal.II's version Utilities::MPI::broadcast, to get the solution to all 
MPI ranks (typically with another collective to make all ranks agree on 
who sends the information).


Best,
Martin

This is a variant that allows the evaluation even on remote processes.

On 24.08.21 14:05, Hermes Sampedro wrote:

Dear all,

I am trying to extend my implementation with parallel computing. I 
would like to get the solution in a single point when having a 
distributed system. For example, in step-40 I have the 
/locally_relevant_solution/ at the output_result(...) function.

In a non distributed implementation I used:

Vector<*double*> vecSol (fe.n_components());

VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2),vecSol);


What is the easiest way to do that? Is it possible to check if the 
point is inside the /locally_relevant_solution? /Or would be more 
appropriate to create a copy of the solution in a global vector and 
get the point from there?



Thank you

H


El mié, 11 ago 2021 a las 10:12, Hermes Sampedro 
(mailto:hermesampe...@gmail.com>>) escribió:


Thank you very much, I could make it work.

Regards,
Hermes

El mar, 10 ago 2021 a las 19:46, Jean-Paul Pelteret
(mailto:jppelte...@gmail.com>>) escribió:

Another thing: You probably also need to initialise with the
right number of components. So something like
Vector vecSol (fe.n_components());



On 10. Aug 2021, at 19:40, Jean-Paul Pelteret
mailto:jppelte...@gmail.com>> wrote:

Hi Hermes,

You don’t say what errors you’re seeing, but my guess is that
it now doesn’t compile. This variant of the function (the one
that Daniel linked to) returns void, so you should call it
before outputting the result:

Vector vecSol;
VectorTools::point_value(dof_handler,
solution,Point<2>(0.2, 0.2),vecSol)
std::cout << "Solution at (0.2,0.2): "<< vecSol << std::endl;

This will hopefully get you what you want.

Best,
Jean-Paul



On 10. Aug 2021, at 16:09, Hermes Sampedro
mailto:hermesampe...@gmail.com>>
wrote:

Thank you for your answer. I am not sure if I fully
understand your suggestion. Do you mean something like that:

Vector<*double*> vecSol;
std::cout <<"Solution at (0.2,0.2): "<<
VectorTools::point_value(dof_handler,
solution,Point<2>(0.2,0.2),vecSol)<< std::endl;


I still get some errors. Is there not any way to get for
example the real part of/solution/ easily and use it
directly on the point_value as in step-3?

Thank you
H

El mar, 10 ago 2021 a las 15:49, Daniel Arndt
(mailto:d.arndt.m...@gmail.com>>)
escribió:

Hermes,

Use another overload. The one returning the solution as
a parameter should

work:https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#acd358e9b110ccbf4a7f76796d206b9c7



Best,
Daniel

Am Di., 10. Aug. 2021 um 09:41 Uhr schrieb Hermes
Sampedro mailto:hermesampe...@gmail.com>>:

Dear all,

It is explained in Step-3 how to evaluate the
solution in a point. I am trying to do the same for
Step-29, to evaluate the real and imaginary parts
separately in a single point:

/std::cout << "Solution at (0.2,0.2): "<<
VectorTools::point_value(dof_handler,
solution,Point<2>(0.2, 0.2))<< std::endl;/

I do not have any problems compiling however, an
error occurs when running:

/The violated condition
was:  dof.get_fe(0).n_components() == 1/

What is the proper way to call the real and
imaginary parts of the solution at a particular
point here?


Thank you very much!

H.


--
The deal.II project is located
athttp://www.dealii.org/ 
For mailing list/forum options,
seehttps://groups.google.com/d/forum/dealii?hl=en

---
You received this message because you are subscribed
to the Google

Re: [deal.II] point_value, Real parts, step-29

2021-08-24 Thread Hermes Sampedro

Dear all,

I am trying to extend my implementation with parallel computing. I would
like to get the solution in a single point when having a distributed
system. For example, in step-40 I have the *locally_relevant_solution* at
the output_result(...) function.
In a non distributed implementation I used:

  Vector<*double*> vecSol (fe.n_components());

  VectorTools::point_value(dof_handler, solution,Point<2>(0.2,
0.2),vecSol);


What is the easiest way to do that? Is it possible to check if the point is
inside the *locally_relevant_solution? *Or would be more appropriate to
create a copy of the solution in a global vector and get the point from
there?


Thank you

H

El mié, 11 ago 2021 a las 10:12, Hermes Sampedro ()
escribió:

> Thank you very much, I could make it work.
>
> Regards,
> Hermes
>
> El mar, 10 ago 2021 a las 19:46, Jean-Paul Pelteret ()
> escribió:
>
>> Another thing: You probably also need to initialise with the right
>> number of components. So something like
>> Vector vecSol (fe.n_components());
>>
>>
>> On 10. Aug 2021, at 19:40, Jean-Paul Pelteret 
>> wrote:
>>
>> Hi Hermes,
>>
>> You don’t say what errors you’re seeing, but my guess is that it now
>> doesn’t compile. This variant of the function (the one that Daniel linked
>> to) returns void, so you should call it before outputting the result:
>>
>> Vector vecSol;
>> VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2),vecSol)
>> std::cout << "Solution at (0.2,0.2): "<< vecSol << std::endl;
>>
>> This will hopefully get you what you want.
>>
>> Best,
>> Jean-Paul
>>
>>
>> On 10. Aug 2021, at 16:09, Hermes Sampedro 
>> wrote:
>>
>> Thank you for your answer. I am not sure if I fully understand your
>> suggestion. Do you mean something like that:
>>
>>  Vector<*double*> vecSol;
>>  std::cout << "Solution at (0.2,0.2): "<<
>> VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2),vecSol)<<
>> std::endl;
>>
>>
>> I still get some errors. Is there not any way to get for example the real
>> part of *solution* easily and use it directly on the point_value as in
>> step-3?
>>
>> Thank you
>> H
>>
>> El mar, 10 ago 2021 a las 15:49, Daniel Arndt ()
>> escribió:
>>
>>> Hermes,
>>>
>>> Use another overload. The one returning the solution as a parameter
>>> should work:
>>> https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#acd358e9b110ccbf4a7f76796d206b9c7
>>>
>>> Best,
>>> Daniel
>>>
>>> Am Di., 10. Aug. 2021 um 09:41 Uhr schrieb Hermes Sampedro <
>>> hermesampe...@gmail.com>:
>>>
 Dear all,

 It is explained in Step-3 how to evaluate the solution in a point. I am
 trying to do the same for Step-29, to evaluate the real and imaginary parts
 separately in a single point:

 *std::cout << "Solution at (0.2,0.2): "<<
 VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2))<<
 std::endl;*

 I do not have any problems compiling however, an error occurs when
 running:

 *The violated condition was:  dof.get_fe(0).n_components() == 1*

 What is the proper way to call the real and imaginary parts of the
 solution at a particular point here?


 Thank you very much!

 H.

 --
 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/54a2d44e-194a-43c0-aa7f-9fddd5bd0dean%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 a topic in the
>>> Google Groups "deal.II User Group" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/dealii/Ru1_uMbix30/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/CAOYDWb%2BR0bRTVxB-F22Hwk_ZexN4%3DVwCbZ7ZKqs3JjEaHFhncA%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

[deal.II] Re: shift-invert transformation problem with slepc

2021-08-24 Thread simon...@gmail.com

Hi,

I think you need to set both which eigen pair and the target value. For 
example, if you look for the eigenvalue closest in magnitude to 0, you need 
to set the following

const double target_eigenvalue = 0;
eigensolver.set_which_eigenpairs(EPS_TARGET_MAGNITUDE);
eigensolver.set_target_eigenvalue(target_eigenvalue);

Depending on slepc version it might be that you can only choose 
EPS_TARGET_MAGNITUDE. See question 8 here:

https://slepc.upv.es/documentation/faq.htm

Best,
Simon

On Tuesday, August 24, 2021 at 3:39:29 AM UTC+2 anton.i...@gmail.com wrote:

> Dear All,
>
> I am trying to use a shift-invert transformation in step-36. I did minimal 
> changes in the solve function adding the following code that describes what 
> spectral transformation I need to do:
>
> SolverControl solver_control (dof_handler.n_dofs(), 1e-9);
> SLEPcWrappers::SolverKrylovSchur eigensolver(solver_control);
> eigensolver.set_which_eigenpairs (EPS_SMALLEST_REAL);
> eigensolver.set_problem_type (EPS_GHEP);
>
> double eigen_shift = 1.0e-4;
> SLEPcWrappers::TransformationShiftInvert::AdditionalData 
> additional_data(eigen_shift);
> SLEPcWrappers::TransformationShiftInvert shift (MPI_COMM_WORLD, 
> additional_data);
> eigensolver.set_transformation (shift);
>
> eigensolver.solve(stiffness_matrix,
>   mass_matrix,
>   eigenvalues,
>   eigenfunctions,
>   eigenfunctions.size());
>
> and it gives me the following error: 
>
> [0]PETSC ERROR: Shift-and-invert requires a target 'which' (see 
> EPSSetWhichEigenpairs), for instance -st_type sinvert -eps_target 0 
> -eps_target_magnitude
>
> Any help to resolve this error is greatly appreciated. I also attached the 
> full code of modified step-36.
>
> Thank you,
> Anton.
>

-- 
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/ada0420b-83b5-4af0-a77c-d71c9af63dd6n%40googlegroups.com.

[deal.II] Re: shift-invert transformation problem with slepc

[deal.II] deal.II Newsletter #179

Re: [deal.II] point_value, Real parts, step-29

Re: [deal.II] point_value, Real parts, step-29

Re: [deal.II] point_value, Real parts, step-29

Re: [deal.II] point_value, Real parts, step-29

Re: [deal.II] point_value, Real parts, step-29

Re: [deal.II] point_value, Real parts, step-29

[deal.II] Re: shift-invert transformation problem with slepc

9 matches

Site Navigation

Mail list logo

Footer information