freepooma-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pooma-dev] Problem with Field::makeOwnCopy() and Relations


From: Richard Guenther
Subject: Re: [pooma-dev] Problem with Field::makeOwnCopy() and Relations
Date: Thu, 22 May 2003 09:58:43 +0200 (CEST)

On Wed, 21 May 2003, John H. Hall wrote:

>
> On Wednesday, May 21, 2003, at 01:41  PM, Richard Guenther wrote:
>
> > Not only because you cannot take views of fields with >1
> > subfields and calling field.physicalDomain() is "undefined" for fields
> > with >1 subfield.
> >
>
> I remember the reason for the field.physicalDomain() being defined only
> at the innermost subFields (what would it mean at higher levels since
> it is different for each direction and centering?)

I agree a generic physicalDomain() on a multi-subfield Field does not make
sense very much, but

Domain_t FieldEngine::physicalDomain() const
{
  if (centeringSize() == 1)
     return cellDomainToCenteringDomain(physicalCellDomain_m, centering_m, 0);
  else
     return physicalCellDomain_m;
}

will probably lead to unexpected results for the "unexperienced" user.
Note that FieldEngine::physicalDomain(int centering) does the right thing
here.

Either I'd expect the above to always return the physical domain of
centering zero, or to abort in the multi-subfield case.


> But, I don't
> remember a restriction on taking views of edge-centered fields for
> example. We took views of these things all over the place. In fact our
> field object factory was in the unoptimized case up to the second view
> (third object) by the time we returned from its create function call. I
> think you will have to be more specific in what you mean here.

Hmm - I refer to

Field.h:
struct View1Implementation<Field<Mesh, T, EngineTag>, Domain,
true>::make

where I can read

   PAssert(f.numSubFields() == 0);

and I stumbled over it yesterday (just noticed when I had -DNOPAssert off,
it _did_ seem to work without - but I'm not sure). Ah I see - this is for
Loc/int views only, so this seems to make sense. Hmm - maybe I need to go
back and look where I got this failure.

Btw. I'm coming across all these limitations/bugs while playing with
ScalarCode and Fields.

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]