octave-maintainers
[Top][All Lists]
Advanced

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

RE: blog update #2


From: Marco Vassallo
Subject: RE: blog update #2
Date: Tue, 18 Jun 2013 14:19:28 +0200

> Subject: Re: blog update #2
> From: address@hidden
> Date: Tue, 18 Jun 2013 13:37:32 +0200
> CC: address@hidden
> To: address@hidden
>
>
> On 18 Jun 2013, at 13:23, Marco Vassallo <address@hidden> wrote:
> >
> >
> > I have a question about the (p,e,t) format, which seems to have a little differences between the
> > 2D and the 3D case for the "e" matrix:
> >
> > 2D: information about the number of the border is stored in the 5th row on 7.[1]
> > 3D: the same information is stored in the last row.[2]
> >
> > Is this right ?
>
> it really seems so from the documentation …
> but indeed this looks inconsistent, to double check you could look at the source code of
>
> bim3c_unknowns_on_faces
>
> and
>
> bim2c_unknowns_on_side
>
> which sure work correctly to see whether it is a documentation bug.

Hi,

I checked the

msh2m_nodes_on_side

and

msh3m_nodes_on_face

which are used by the bim pkg and it is exactly as described in the msh documentation..

> Anyway the data structures was modeled by compatibility with pdetool
> and ancient versions of comsol multyphisics, keeping this compatibility
> does not make too much sense anymore so if there is a good reason the formats may be changed.
>

No problem, it was just to write a unified code for the 2D and 3D case writing the information in the last line od the "e" matrix.. but as 5 and 10 are just D^2 +1 I can avoid another if() statement.

thanks

marco

> c.



reply via email to

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