date:20170324

Re: [deal.II] Re: making a package of PETSc vectors

2017-03-24 Thread itomas

No worried, 

VectorPacket[0].reset(new PETScWrappers::MPI::Vector(locally_owned_dofs, 
mpi_communicator) ) ;

now did the job.

Thanks.


On Friday, March 24, 2017 at 8:01:18 PM UTC-5, Ignacio Tomas wrote:
>
> I wanted to do something like (in reality I would do this with a for loop)
>
> std::vector< std::shared_ptr > VectorPacket ;
> VectorPacket.resize(3) ; 
> VectorPacket[0].reset(new PETScWrappers::MPI::Vector) ;
> VectorPacket[1].reset(new PETScWrappers::MPI::Vector) ;
> VectorPacket[2].reset(new PETScWrappers::MPI::Vector) ;
>
> and later initialize all of them (with a for loop too). Yet this does not 
> seem to work. Otherwise
>
> std::vector< std::shared_ptr > VectorPacket ;
> VectorPacket.resize(3) ; 
> VectorPacket[0].reset() ;
> VectorPacket[1].reset() ;
> VectorPacket[2].reset() ;
>
> with Vect1, Vect2 and Vect3 defined/declared/initialized a priori works 
> fine. But it comes with the overhead of definining these vectors separately 
> rather than with the the vector of shared pointers. 
>
> On Fri, Mar 24, 2017 at 1:50 AM, Jean-Paul Pelteret  
> wrote:
>
>> Dear Itomas,
>>
>> I would recommend going the route suggested in this recent post 
>> ,
>>  
>> namely creating a vector of shared pointers of PETSc vectors, i.e. 
>> std::vector. Using shared 
>> pointers means that you safeguard against memory leaks, and can be stored 
>> as entries in a vector. That would give you the flexibility that you 
>> require with a minimal interface change to your code (apart from how you 
>> create the vectors initially, you would need to dereference these vector 
>> entries with the "->" operator instead of the "." operator). 
>>
>> I hope that this helps.
>> Best regards,
>> Jean-Paul
>>
>> On Friday, March 24, 2017 at 2:37:07 AM UTC+1, ito...@tamu.edu wrote:
>>>
>>> Dear everybody:
>>>
>>> I don't have any particular problem, just trying to streamline a code. I 
>>> am have a mess with the interfaces of my code, in particular with the 
>>> functions and classes I have created, primarily because I have to handle a 
>>> ''packet'' of vectors, say 
>>>
>>> PETScWrappers::MPI::Vector  Vect1;
>>> PETScWrappers::MPI::Vector  Vect2;
>>> PETScWrappers::MPI::Vector  Vect3;
>>> PETScWrappers::MPI::Vector  Vect4;
>>> …
>>> PETScWrappers::MPI::Vector  Vect7;
>>>
>>> and use them either as input or output arguments of some functions, 
>>> solvers, complementary computations, etc. This is quite cumbersome, and as 
>>> solution I naively thought I could do the following
>>>
>>> std::vector  VectorPacket ;
>>> VectorPacket.resize(7) ;
>>> for (int i=0; i<7 ; ++i) 
>>>   VectorPacket[i].reinit (locally_owned_dofs, mpi_communicator ) ;
>>>
>>> So, now VectorPacket is really a packet, rather than seven isolated 
>>> vectors. It is almost needless to say that this is bad idea, std::vector 
>>> will demand quite a few things from the class PETScWrappers::MPI::Vector 
>>> which are just not there (in particular some operators). In reality the 
>>> size of the packet of vector is not always seven, which means that I really 
>>> need to use a proper container for which I can change it's size. Do you 
>>> have any suggestion (a.k.a. creative approach) on how to deal with an issue 
>>> like this one? Which container from the STL would be appropriate?
>>>
>>> Many thanks.
>>>
>> -- 
>> 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/rFm-6ZMYoU4/unsubscribe 
>> 
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> dealii+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout 
>>

Re: [deal.II] Re: making a package of PETSc vectors

2017-03-24 Thread Ignacio Tomas

I wanted to do something like (in reality I would do this with a for loop)

std::vector< std::shared_ptr > VectorPacket ;
VectorPacket.resize(3) ;
VectorPacket[0].reset(new PETScWrappers::MPI::Vector) ;
VectorPacket[1].reset(new PETScWrappers::MPI::Vector) ;
VectorPacket[2].reset(new PETScWrappers::MPI::Vector) ;

and later initialize all of them (with a for loop too). Yet this does not
seem to work. Otherwise

std::vector< std::shared_ptr > VectorPacket ;
VectorPacket.resize(3) ;
VectorPacket[0].reset() ;
VectorPacket[1].reset() ;
VectorPacket[2].reset() ;

with Vect1, Vect2 and Vect3 defined/declared/initialized a priori works
fine. But it comes with the overhead of definining these vectors separately
rather than with the the vector of shared pointers.

On Fri, Mar 24, 2017 at 1:50 AM, Jean-Paul Pelteret 
wrote:

> Dear Itomas,
>
> I would recommend going the route suggested in this recent post
> ,
> namely creating a vector of shared pointers of PETSc vectors, i.e.
> std::vector. Using shared
> pointers means that you safeguard against memory leaks, and can be stored
> as entries in a vector. That would give you the flexibility that you
> require with a minimal interface change to your code (apart from how you
> create the vectors initially, you would need to dereference these vector
> entries with the "->" operator instead of the "." operator).
>
> I hope that this helps.
> Best regards,
> Jean-Paul
>
> On Friday, March 24, 2017 at 2:37:07 AM UTC+1, ito...@tamu.edu wrote:
>>
>> Dear everybody:
>>
>> I don't have any particular problem, just trying to streamline a code. I
>> am have a mess with the interfaces of my code, in particular with the
>> functions and classes I have created, primarily because I have to handle a
>> ''packet'' of vectors, say
>>
>> PETScWrappers::MPI::Vector  Vect1;
>> PETScWrappers::MPI::Vector  Vect2;
>> PETScWrappers::MPI::Vector  Vect3;
>> PETScWrappers::MPI::Vector  Vect4;
>> …
>> PETScWrappers::MPI::Vector  Vect7;
>>
>> and use them either as input or output arguments of some functions,
>> solvers, complementary computations, etc. This is quite cumbersome, and as
>> solution I naively thought I could do the following
>>
>> std::vector  VectorPacket ;
>> VectorPacket.resize(7) ;
>> for (int i=0; i<7 ; ++i)
>>   VectorPacket[i].reinit (locally_owned_dofs, mpi_communicator ) ;
>>
>> So, now VectorPacket is really a packet, rather than seven isolated
>> vectors. It is almost needless to say that this is bad idea, std::vector
>> will demand quite a few things from the class PETScWrappers::MPI::Vector
>> which are just not there (in particular some operators). In reality the
>> size of the packet of vector is not always seven, which means that I really
>> need to use a proper container for which I can change it's size. Do you
>> have any suggestion (a.k.a. creative approach) on how to deal with an issue
>> like this one? Which container from the STL would be appropriate?
>>
>> Many thanks.
>>
> --
> 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/rFm-6ZMYoU4/unsubscribe
> 
> .
> To unsubscribe from this group and all its topics, 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

Re: [deal.II] Re: making a package of PETSc vectors

2017-03-24 Thread Ignacio Tomas

Thanks, I will definitely try it.

Ignacio.

On Fri, Mar 24, 2017 at 1:50 AM, Jean-Paul Pelteret 
wrote:

> Dear Itomas,
>
> I would recommend going the route suggested in this recent post
> ,
> namely creating a vector of shared pointers of PETSc vectors, i.e.
> std::vector. Using shared
> pointers means that you safeguard against memory leaks, and can be stored
> as entries in a vector. That would give you the flexibility that you
> require with a minimal interface change to your code (apart from how you
> create the vectors initially, you would need to dereference these vector
> entries with the "->" operator instead of the "." operator).
>
> I hope that this helps.
> Best regards,
> Jean-Paul
>
> On Friday, March 24, 2017 at 2:37:07 AM UTC+1, ito...@tamu.edu wrote:
>>
>> Dear everybody:
>>
>> I don't have any particular problem, just trying to streamline a code. I
>> am have a mess with the interfaces of my code, in particular with the
>> functions and classes I have created, primarily because I have to handle a
>> ''packet'' of vectors, say
>>
>> PETScWrappers::MPI::Vector  Vect1;
>> PETScWrappers::MPI::Vector  Vect2;
>> PETScWrappers::MPI::Vector  Vect3;
>> PETScWrappers::MPI::Vector  Vect4;
>> …
>> PETScWrappers::MPI::Vector  Vect7;
>>
>> and use them either as input or output arguments of some functions,
>> solvers, complementary computations, etc. This is quite cumbersome, and as
>> solution I naively thought I could do the following
>>
>> std::vector  VectorPacket ;
>> VectorPacket.resize(7) ;
>> for (int i=0; i<7 ; ++i)
>>   VectorPacket[i].reinit (locally_owned_dofs, mpi_communicator ) ;
>>
>> So, now VectorPacket is really a packet, rather than seven isolated
>> vectors. It is almost needless to say that this is bad idea, std::vector
>> will demand quite a few things from the class PETScWrappers::MPI::Vector
>> which are just not there (in particular some operators). In reality the
>> size of the packet of vector is not always seven, which means that I really
>> need to use a proper container for which I can change it's size. Do you
>> have any suggestion (a.k.a. creative approach) on how to deal with an issue
>> like this one? Which container from the STL would be appropriate?
>>
>> Many thanks.
>>
> --
> 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/rFm-6ZMYoU4/unsubscribe
> 
> .
> To unsubscribe from this group and all its topics, 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.

[deal.II] Avoid holding matrices in vector for MeshWorker

2017-03-24 Thread Franco Milicchio

Dear all,

I have seen that MeshWorker with the MatrixSimple assembler has an 
initialize member that needs a vector of matrices. However that isn't 
really good for my case, as I'd like to assign ownership of matrices as I 
wish, not necessarily to a vector.

Is there any possibility to assemble in parallel several matrices without 
having a vector of matrices? For instance, the ResidualSimple assembles 
vectors, but can use pointers, as in this code:

// Data containing pointers to vectors

AnyData data;



// Add them all

data.add(_rhs,  "rhs");

data.add(_rhs2, "rhs2");

No class, as far as I've seen, can do this with matrices using AnyData or 
any other workaround.

Did I miss something?

Thanks!
Franco

-- 
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: [dealii-developers] authors.html format

2017-03-24 Thread Jean-Paul Pelteret

Ditto.

On Thursday, March 23, 2017 at 8:49:56 PM UTC+1, Matthias Maier wrote:
>
>
> On Thu, Mar 23, 2017, at 14:38 CDT, Timo Heister  
> wrote: 
>
> > Hey all, 
> > 
> > the AUTHORS file for a specific release (see 
> > 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dealii_dealii_blob_dealii-2D8.4_AUTHORS=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=bIZ1PN9GFeiDFVPWRQ7rHwsFOCnh0BavuhRERQ4RDWGqJOxfLu0FfCOxyifWO5wc=puLyHrLG-0I2mb3GlhSy8fw8Zh5Uy4NZEuglia1sknM=SW2IV7CFJlag6Wpb7_CXIAaXftdJrEJg6IP24P3oxT8=
>  
> > for the last 
> > example) is built manually from 
> > 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.dealii.org_authors.html=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=bIZ1PN9GFeiDFVPWRQ7rHwsFOCnh0BavuhRERQ4RDWGqJOxfLu0FfCOxyifWO5wc=puLyHrLG-0I2mb3GlhSy8fw8Zh5Uy4NZEuglia1sknM=d8tjNXJVl3idAE4vWr87zDtPnckT04J1jpcQM9puyys=
>  
> > which we need to update before every release. The problem is that 
> > authors.html contains a description on what the contributions are. 
> > 
> > I would vote to remove these descriptions from authors.html for the 
> > following reasons: 
> > 1. a lot of work to maintain 
> > 2. most of them are likely out of date already anyways 
> > 3. less work for release paper, release announcement, and AUTHORS file. 
> > 
> > Sounds good? 
>
> Sounds good to me. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"deal.II developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: making a package of PETSc vectors

2017-03-24 Thread Jean-Paul Pelteret

Dear Itomas,

I would recommend going the route suggested in this recent post 
, namely 
creating a vector of shared pointers of PETSc vectors, i.e. 
std::vector. Using shared 
pointers means that you safeguard against memory leaks, and can be stored 
as entries in a vector. That would give you the flexibility that you 
require with a minimal interface change to your code (apart from how you 
create the vectors initially, you would need to dereference these vector 
entries with the "->" operator instead of the "." operator). 

I hope that this helps.
Best regards,
Jean-Paul

On Friday, March 24, 2017 at 2:37:07 AM UTC+1, ito...@tamu.edu wrote:
>
> Dear everybody:
>
> I don't have any particular problem, just trying to streamline a code. I 
> am have a mess with the interfaces of my code, in particular with the 
> functions and classes I have created, primarily because I have to handle a 
> ''packet'' of vectors, say 
>
> PETScWrappers::MPI::Vector  Vect1;
> PETScWrappers::MPI::Vector  Vect2;
> PETScWrappers::MPI::Vector  Vect3;
> PETScWrappers::MPI::Vector  Vect4;
> …
> PETScWrappers::MPI::Vector  Vect7;
>
> and use them either as input or output arguments of some functions, 
> solvers, complementary computations, etc. This is quite cumbersome, and as 
> solution I naively thought I could do the following
>
> std::vector  VectorPacket ;
> VectorPacket.resize(7) ;
> for (int i=0; i<7 ; ++i) 
>   VectorPacket[i].reinit (locally_owned_dofs, mpi_communicator ) ;
>
> So, now VectorPacket is really a packet, rather than seven isolated 
> vectors. It is almost needless to say that this is bad idea, std::vector 
> will demand quite a few things from the class PETScWrappers::MPI::Vector 
> which are just not there (in particular some operators). In reality the 
> size of the packet of vector is not always seven, which means that I really 
> need to use a proper container for which I can change it's size. Do you 
> have any suggestion (a.k.a. creative approach) on how to deal with an issue 
> like this one? Which container from the STL would be appropriate?
>
> Many thanks.
>

-- 
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.

[deal.II] Re: Vertices constraints inside the domain

2017-03-24 Thread Jean-Paul Pelteret

Hi Seven,

Thanks for reporting back that you missed a step in the application of the 
constraints! I'm glad that you managed to solve your problem.

Best regards,
Jean-Paul

On Friday, March 24, 2017 at 2:09:35 AM UTC+1, seven wrote:
>
> Guess I figured it out. I didn't do 
> constraints.distribute();
>
>
> 在 2017年3月23日星期四 UTC-4上午1:38:32，seven写道：
>>
>>
>> Hello all,
>>
>> I am trying to project a solution in FE_DGP(sol_dg) to FE_Q (sol_cg), but 
>> I only know the gradients of sol_dg and its values at some vertices, so I 
>> want to fix values of sol_cg at the same vertices after the projection.
>>
>> The first method I tried is quite straightforward, but the resulting 
>> global matirx is very ill-conditioned. I set the corresponding row to zero 
>> except the diagonal entry, and then change the right hand size.
>>
>> for( ; cell_c!= endc;++cell_dg, ++cell_c ){
>> const unit active_index = cell_dg->active_cell_index();
>> if(interface_flag[active_index] == 1){
>> fe_values_continuous.reinit(cell_c);
>> fe_values_v_dg.reinit(cell_dg);
>> fe_values_v_dg.get_function_values(solution, solu_dg);
>> cell_c->get_dof_indices(local_dof_indices_c);
>> for(unit vert=0; vert<4; ++vert){
>> // local_dof_indices_c[vert] global index
>> const unit index_i = local_dof_indices_c[vert];
>> ls_rhs_continuous(index_i) = solu_dg[vert]* aver_diag;
>> for(unit i=0; i> ls_matrix_continuous.set(local_dof_indices_c[vert], i, 0.);
>> ls_matrix_continuous.set(index_i, index_i, aver_diag);
>> }
>> }
>>
>> } 
>> so I want to use constraint matrix to do the same thing, but cannot get 
>> the right answer. 
>>
>> for( ; cell_c!= endc;++cell_dg, ++cell_c ){
>> const unit active_index = cell_dg->active_cell_index();
>> if(interface_flag[active_index] == 1){
>> fe_values_continuous.reinit(cell_c);
>> fe_values_v_dg.reinit(cell_dg);
>> fe_values_v_dg.get_function_values(solution, solu_dg);
>> cell_c->get_dof_indices(local_dof_indices_c);
>> for(unit vert=0; vert<4; ++vert){
>> // local_dof_indices_c[vert] global index
>> const unit index_i = local_dof_indices_c[vert];
>> constraints.add_line(index_i);
>> constraints.set_inhomogeneity(index_i, solu_dg[vert]);
>> }
>> }
>> }
>> constraints.close();
>>
>> cell_c = dof_handler_continuous.begin_active();
>> cell_dg = dof_handler.begin_active();
>> for( ; cell_c!=endc; ++cell_c, ++cell_dg){
>> fe_values_dg.reinit(cell_dg);
>> fe_values_dg.get_function_gradients(solution, grad_dg);
>>
>> ls_matrix = 0;
>> ls_rhs = 0;
>> fe_values_continuous.reinit(cell_c);
>>
>> for(unit q=0; q> for(unit i=0; i> ls_rhs(i) += fe_values_continuous.shape_grad(i,q)
>>   * fe_values_continuous.JxW(q)
>>   * grad_dg[q];
>> for(unit j=0; j> ls_matrix(i,j) += fe_values_continuous.shape_grad(i,q)
>>* fe_values_continuous.shape_grad(j,q)
>>* fe_values_continuous.JxW(q);
>> }
>> }
>> cell_c->get_dof_indices(local_dof_indices_c);
>> constraints.distribute_local_to_global (ls_matrix, ls_rhs,
>> local_dof_indices_c,
>> ls_matrix_continuous, 
>> ls_rhs_continuous);
>>
>> Any help would be appreciated
>>
>> Thanks,
>> Jiaqi 
>>
>

-- 
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: making a package of PETSc vectors

Re: [deal.II] Re: making a package of PETSc vectors

Re: [deal.II] Re: making a package of PETSc vectors

[deal.II] Avoid holding matrices in vector for MeshWorker

Re: [dealii-developers] authors.html format

[deal.II] Re: making a package of PETSc vectors

[deal.II] Re: Vertices constraints inside the domain

7 matches

Site Navigation

Mail list logo

Footer information