Re: [deal.II] Error in complex GMRES

2022-09-27 Thread 'yy.wayne' via deal.II User Group
Yeah I think it make sense. Thank you again.

在2022年9月28日星期三 UTC+8 11:08:17 写道:

> On 9/27/22 21:02, 'yy.wayne' via deal.II User Group wrote:
> > 
> > Just one last question. So if I have the same problem coded in 
> real+imaginary 
> > or complex and solve with SparseDirect solver or Krylov subspace 
> methods. Will 
> > there be difference in time consumption (due to larger matirx / or 
> harder to 
> > solve complex arithmetic embedded in those solver)?
>
> For Krylov subspace methods, everything depends on the preconditioner and 
> it 
> is not possible to make general predictions without knowing what you want 
> to 
> use for the preconditioner.
>
> For SparseDirectUMFPACK, I suspect that using complex arithmetic is faster 
> than using separate real/imaginary components. By how much is something I 
> have 
> never measured -- you probably need to measure this yourself. It would not 
> greatly surprise me if it was faster by a factor of 4 or 6, but I don't 
> think 
> it should be a factor of 20 for example.
>
> Best
> Wolfgang
>
> -- 
> 
> Wolfgang Bangerth email: bang...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/f6e6257b-33df-4e91-9bfb-bd3b05d1973dn%40googlegroups.com.


Re: [deal.II] Error in complex GMRES

2022-09-27 Thread Wolfgang Bangerth

On 9/27/22 21:02, 'yy.wayne' via deal.II User Group wrote:


Just one last question. So if I have the same problem coded in real+imaginary 
or complex and solve with SparseDirect solver or Krylov subspace methods. Will 
there be difference in time consumption (due to larger matirx / or harder to 
solve complex arithmetic embedded in those solver)?


For Krylov subspace methods, everything depends on the preconditioner and it 
is not possible to make general predictions without knowing what you want to 
use for the preconditioner.


For SparseDirectUMFPACK, I suspect that using complex arithmetic is faster 
than using separate real/imaginary components. By how much is something I have 
never measured -- you probably need to measure this yourself. It would not 
greatly surprise me if it was faster by a factor of 4 or 6, but I don't think 
it should be a factor of 20 for example.


Best
 Wolfgang

--

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/e38d17ef-ef0b-0361-ec81-1732de6b7cab%40colostate.edu.


Re: [deal.II] Error in complex GMRES

2022-09-27 Thread 'yy.wayne' via deal.II User Group
Thank you sir.

Just one last question. So if I have the same problem coded in 
real+imaginary or complex and solve with SparseDirect solver or Krylov 
subspace methods. Will there be difference in time consumption (due to 
larger matirx / or harder to solve complex arithmetic embedded in those 
solver)?

在2022年9月28日星期三 UTC+8 10:57:13 写道:

> On 9/27/22 20:52, 'yy.wayne' via deal.II User Group wrote:
> > I'm using the Oracle VirtualBox environment by default, so I guess it's 
> not 
> > complied with PETSc complex arithmetic.
>
> Yes, that's probably true. You will have to install things from scratch on 
> your system if you want PETSc with complex arithmetic. It is a pity that 
> PETSc 
> doesn't make that easy :-(
>
>
> > By the way, is using complex coding approved or separate to real and 
> imaginary 
> > parts? I read another discussion in gouglegroup said complex coding 
> might lead 
> > to error for   integral. But separate a problem into real and 
> > imaginary doubles the matirx size and DoFs, isn't it?
>
> Well yes, but then you do need to store real and imaginary parts somewhere 
> anyway. So this isn't likely going to be a big bottleneck.
>
> The post you refer to simply points out that it is easy to make mistakes 
> if 
> you work in complex, rather than separate real/imaginary, arithmetic. But 
> it 
> can be done correctly, as shown in step-58.
>
> Best
> W.
>
> -- 
> 
> Wolfgang Bangerth email: bang...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/04ced81f-0cb7-4b9c-970c-84926ae4fb14n%40googlegroups.com.


Re: [deal.II] Error in complex GMRES

2022-09-27 Thread Wolfgang Bangerth

On 9/27/22 20:52, 'yy.wayne' via deal.II User Group wrote:
I'm using the Oracle VirtualBox environment by default, so I guess it's not 
complied with PETSc complex arithmetic.


Yes, that's probably true. You will have to install things from scratch on 
your system if you want PETSc with complex arithmetic. It is a pity that PETSc 
doesn't make that easy :-(



By the way, is using complex coding approved or separate to real and imaginary 
parts? I read another discussion in gouglegroup said complex coding might lead 
to error for   integral. But separate a problem into real and 
imaginary doubles the matirx size and DoFs, isn't it?


Well yes, but then you do need to store real and imaginary parts somewhere 
anyway. So this isn't likely going to be a big bottleneck.


The post you refer to simply points out that it is easy to make mistakes if 
you work in complex, rather than separate real/imaginary, arithmetic. But it 
can be done correctly, as shown in step-58.


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/022e3dbb-6cef-0167-cd75-1feec762c155%40colostate.edu.


Re: [deal.II] Error in complex GMRES

2022-09-27 Thread 'yy.wayne' via deal.II User Group
Thank you.
I'm using the Oracle VirtualBox environment by default, so I guess it's not 
complied with PETSc complex arithmetic.
By the way, is using complex coding approved or separate to real and 
imaginary parts? I read another discussion in gouglegroup said complex 
coding might lead to error for   integral. But separate a problem 
into real and imaginary doubles the matirx size and DoFs, isn't it?

在2022年9月28日星期三 UTC+8 10:47:51 写道:

> On 9/27/22 00:25, 'yy.wayne' via deal.II User Group wrote:
> > As I changing built-in solver to PETScWrappers, I failed to converse a 
> > "PETSc::Wrappers:Vector" variable to a "Vector>" 
> one, as 
> > shown in line 464 of my code. I tried
> > "Vector> a = b; (where b is a PETSc Vector)"
> > or
> > "Vector> a(b)"
> > but both failed. In step-17 however, both is good. Is it because the 
> complex 
> > type or other mistake inmy code?
> > 
>
> I don't know. You may want to show the compiler's error message.
>
> Did you compile PETSc with the flag necessary to support complex 
> arithmetic?
>
> Best
> W.
>
> -- 
> 
> Wolfgang Bangerth email: bang...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/28ac7468-1671-4b11-9fac-07678908d794n%40googlegroups.com.


Re: [deal.II] Error in complex GMRES

2022-09-27 Thread Wolfgang Bangerth

On 9/27/22 00:25, 'yy.wayne' via deal.II User Group wrote:
As I changing built-in solver to PETScWrappers, I failed to converse a 
"PETSc::Wrappers:Vector" variable to a "Vector>" one, as 
shown in line 464 of my code. I tried

         "Vector> a = b; (where b is a PETSc Vector)"
or
         "Vector> a(b)"
but both failed. In step-17 however, both is good. Is it because the complex 
type or other mistake inmy code?




I don't know. You may want to show the compiler's error message.

Did you compile PETSc with the flag necessary to support complex arithmetic?

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/28758d9b-b7e4-cc03-90ae-f758017207ea%40colostate.edu.


Re: [deal.II] Error in complex GMRES

2022-09-26 Thread 'yy.wayne' via deal.II User Group
Thank you Wolfgang.
As I changing built-in solver to PETScWrappers, I failed to converse a 
"PETSc::Wrappers:Vector" variable to a "Vector>" one, 
as shown in line 464 of my code. I tried 
"Vector> a = b; (where b is a PETSc Vector)"
or
"Vector> a(b)"
but both failed. In step-17 however, both is good. Is it because the 
complex type or other mistake inmy code?

Best
Wayne

在2022年9月26日星期一 UTC+8 23:32:40 写道:

> On 9/26/22 09:22, 'yy.wayne' via deal.II User Group wrote:
> > I'm trying to apply a Krylov solver for complex-valued problem. Basiclly 
> > I have modified step-16 into a complex-valued problem (do not seperate 
> > real and imaginary parts) and solve with direct solver successfully. 
> > However it failed on GMRES solver. Does deal.II built-in GMRES solver 
> > only supprts double type?
>
> Yes. You probably want to take a look at step-58 as well, along with the 
> discussion in the results section there.
>
> Best
> W.
>
> -- 
> 
> Wolfgang Bangerth email: bang...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/ffc4cafc-73b6-4b61-97e5-cc82b2be91c3n%40googlegroups.com.
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 

#include 
#include 
#include 

#include 
#include 

#include 
#include 
#include 

#include 
#include 

#include 
#include 



#include 

#include 

#include 
#include 



// complex valued version of Step29
// adaptive mesh
namespace Step29
{
  using namespace dealii;


  template 
  class DirichletBoundaryValues : public Function>
  {
  public:
DirichletBoundaryValues()
  : Function>(1)
{}

virtual std::complex value(const Point &p, const unsigned int component = 0) const override;
  };

  template 
  std::complex DirichletBoundaryValues::value(const Point &p, const unsigned int component) const
  {
(void)component;
Assert(component==0, ExcIndexRange(component,0,1));
return  std::complex(1,0);
  }


  class ParameterReader : public Subscriptor
  {
  public:
ParameterReader(ParameterHandler &);
void read_parameters(const std::string &);

  private:
void  declare_parameters();
ParameterHandler &prm;
  };

  ParameterReader::ParameterReader(ParameterHandler ¶mhandler)
: prm(paramhandler)
  {}


  void ParameterReader::declare_parameters()
  {
prm.enter_subsection("Mesh & geometry parameters");
{
  prm.declare_entry("Number of refinements",
"6",
Patterns::Integer(0),
"Number of global mesh refinement steps "
"applied to initial coarse grid");

  prm.declare_entry("Focal distance",
"0.3",
Patterns::Double(0),
"Distance of the focal point of the lens "
"to the x-axis");
}
prm.leave_subsection();

prm.enter_subsection("Physical constants");
{
  prm.declare_entry("c", "1.5e5", Patterns::Double(0), "Wave speed");

  prm.declare_entry("omega", "5.0e7", Patterns::Double(0), "Frequency");
}
prm.leave_subsection();


prm.enter_subsection("Output parameters");
{
  prm.declare_entry("Output filename",
"solution",
Patterns::Anything(),
"Name of the output file (without extension)");

  DataOutInterface<1>::declare_parameters(prm);
}
prm.leave_subsection();
  }


  void ParameterReader::read_parameters(const std::string ¶meter_file)
  {
declare_parameters();

prm.parse_input(parameter_file);
  }






  template 
  class ComputeIntensity : public DataPostprocessorScalar
  {
  public:
ComputeIntensity();

virtual void evaluate_vector_field(
  const DataPostprocessorInputs::Vector &inputs,
  std::vector> &computed_quantities) const override;
  };

  template 
  ComputeIntensity::ComputeIntensity()
: DataPostprocessorScalar("Intensity", update_values)
  {}


  template 
  void ComputeIntensity::evaluate_vector_field(
const DataPostprocessorInputs::Vector &inputs,
std::vector> &   computed_quantities) const
  {
AssertDimension(computed_quantities.size(), inputs.solution_values.size());

for (unsigned int i = 0; i < computed_quantities.size(); ++i)
   

Re: [deal.II] Error in complex GMRES

2022-09-26 Thread Wolfgang Bangerth

On 9/26/22 09:22, 'yy.wayne' via deal.II User Group wrote:
I'm trying to apply a Krylov solver for complex-valued problem. Basiclly 
I have modified step-16 into a complex-valued problem (do not seperate 
real and imaginary parts) and solve with direct solver successfully. 
However it failed on GMRES solver. Does deal.II built-in GMRES solver 
only supprts double type?


Yes. You probably want to take a look at step-58 as well, along with the 
discussion in the results section there.


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/4ae8f32a-57ea-52a1-6e6a-6fd2415ee750%40colostate.edu.