Re: [Getfem-users] Commit 4120

[Yves Renard]

Dear all,

The copy of mesh, mesh_fem and mesh_im objects is indeed a delicate
question. The problem is that these objects are linked together and
interact to respond to some events like the refinement of the mesh.
In fact, two copy operations can be considered: copy a single object and
a set of linked mesh, mesh_fem and mesh_im.

A copy of a single mesh for instance, should give an mesh which is
linked to no mesh_fem and no mesh_im object.

A copy of a single mesh_fem (or mesh_im) object should give a mesh_fem
still linked to the same mesh as the one of the original mesh_fem (mesh_im).

A copy of a set of linked mesh, mesh_fem and mesh_im should give a set
of correctly linked mesh, mesh_fem and mesh_im objects.

I think, it should be not too much difficult to implement this.

Of course, It is a little bit dangerous since the use of the copy
constructor for mesh_fem and mesh_im object may lead to confusing
situations for a structure gathering a mesh and linked mesh_fem and
mesh_im. Another possibility would be to make private the copy
constructor for the objects mesh_fem and mesh_im and provide a copy
method having for parameter the object to copy and the new mesh.


Yves.






Le 26/07/2012 09:59, Andriy Andreykiv a écrit :
> Hi,
>
> What Roman is pointing out with context_dependecies seems to be the
> root of the problem.
> So, Kostas, may be we can remove the copy constructors and "="
> operators in mesh_fem and
> leave them as they were before my commit, while trying to fix the
> problem with the dependencies,
> unless Roman has already fixed it before going on his holidays  ;) .
> I'll look at it too, although I think
> I'm less familiar with this part of the code.
> This is, of course, more generic solution, as it fixes the problem
> with everything that derives
> context_dependecies. I must say I had a similar problem with
> getfem::mesh (so I think it was similar, I don't
> have that code anymore)
>
> Best regards,
>                      Andriy
>
> On 25 July 2012 20:35, Roman Putanowicz <address@hidden> wrote:
>>> Shouldn't we go through all class members and try to copy as much as
>>> possible? The copy constructor of the mesh_fem class is a very
>>> fundamental point in getfem, we should make sure that the new
>>> constructor is as compatible as possible to the previous behavior.
>>> Kostas
>>>
>> Dear All,
>>
>> I think what Kostas say is very important.
>>
>> In the attachment I have a simple example I wrote to illustrate
>> the issue with context dependencies and copy constructor.
>> It creates a class Foo that inherits from  getfem::context_dependencies
>> and allows to see the pointers stored for context.
>>
>> I have created Master, Slave and Master2 objects. Master and Master2
>> depend on Slave. Master2 is copy of Master (default copy constructor).
>> As you can see the dependent object list for Slave has not been updated
>> to account for Master2.
>>
>> On my machine the output looks like :
>>
>> -------------------------------------------------8<---------
>> Dependent objects for Master 0xbfd0dbb0:
>>      No depentend objects
>> Dependencies objects for Master 0xbfd0dbb0:
>>    0xbfd0db88
>>
>>  --------------
>>
>> Dependent objects for Slave 0xbfd0db88:
>>    0xbfd0dbb0
>> Dependencies objects for Slave 0xbfd0db88:
>>      No dependencies objects
>>
>>  --------------
>>
>> Dependent objects for Master 0xbfd0db60:
>>      No depentend objects
>> Dependencies objects for Master 0xbfd0db60:
>>    0xbfd0db88
>>
>> -------------------------------------------------8<---------
>>
>> Of course name for Master2 is also wrong (the name for 0xbfd0db60
>> should be Master2).
>>
>> This is the issue -- I will look how to fix it unless someone
>> is quicker than me (I am going for holidays on Friday with no coputer :-).
>> I have to understand what the method
>> void sup_dependency(const context_dependencies &cd) does --
>> it looks like it suppres the dependency, so the combination
>> of  add_dependency() and sup_dependency()  should do the job.
>> However I have to draw the dependency tree on paper to be sure
>> I understand whole issue.
>>
>> This is all for now.
>>
>> Regards,
>>
>> Roman
>>
>> --
>> Roman Putanowicz, PhD  < address@hidden  >
>> Institute for Computational Civil Engng (L-5)
>> Dept. of Civil Engng, Cracow Univ. of Technology
>> www.l5.pk.edu.pl, tel. +48 12 628 2569, fax 2034
>>
>> _______________________________________________
>> Getfem-users mailing list
>> address@hidden
>> https://mail.gna.org/listinfo/getfem-users
>>
> _______________________________________________
> Getfem-users mailing list
> address@hidden
> https://mail.gna.org/listinfo/getfem-users


-- 

  Yves Renard (address@hidden)       tel : (33) 04.72.43.87.08
  Pole de Mathematiques, INSA-Lyon             fax : (33) 04.72.43.85.29
  20, rue Albert Einstein
  69621 Villeurbanne Cedex, FRANCE
  http://math.univ-lyon1.fr/~renard

---------