octave-maintainers
[Top][All Lists]
Advanced

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

Re: blog update #2


From: c.
Subject: Re: blog update #2
Date: Fri, 14 Jun 2013 12:31:45 +0200

On 14 Jun 2013, at 12:18, Marco Vassallo <address@hidden> wrote:

> > Subject: Re: blog update #2
> > From: address@hidden
> > Date: Fri, 14 Jun 2013 12:07:31 +0200
> > CC: address@hidden
> > To: address@hidden
> > 
> > 
> > On 14 Jun 2013, at 11:20, c. <address@hidden> wrote:
> > 
> > > Indeed by browsing the python source for the xml_writer I see that the 
> > > dolfin format supports a field named "domains"
> > > which sounds as it could possibly do what you need.
> > 
> > This 3D maesh: http://fenicsproject.org/pub/data/meshes/aneurysm.xml.gz
> > from the dolfin examples page: 
> > http://fenicsproject.org/download/data.html#data
> > 
> > includes boundary markers.
> > c.
> 
> Hi,
> 
> I'm a little bit confused about the problem, and I don't understand if we 
> should:
> 
> 1) improve the mshm_dolfin_read so that we are able
> to import boundary information to Octave, if they are available in the dolfin 
> xml file
> 
> and/or 
> 
> 2) understand how we can add the information that we have stored in the e 
> matrix
> to the dolfin mesh
> 
> Thanks,
> 
> marco

possibly both :)

and also

3) store the subdomain index given in the fourth row of the t matrix into the 
xml file
4) load a mash subdomain marker from a .xml file and put the information in the 
fourth row of the t matrix

the point is that both dolfin and msh/bim do make use of a marker for each 
volume and boundary subdomain 
so a translation of this info from one format to the other is possible and 
should be done, otherwise meshes
imported/exported from one format to the other will be incomplete and difficult 
to use.

I understand that many dolfin tutorials define boundary partitions as functions 
that check for node cooedinates,
but that is a very naive and inconvenient way of doing it.

For example 

1) if you write a program for flow simulation that assumes your computational 
domain to have an 
inlet and an outlet boundary section, if the boundaries are defined from the 
coordinates, you will need to 
recompile your code (or do some nontrivial gymnic with share libraries …) any 
time you change the geometry

2) if the boundary section you want to identify is just slightly more 
complicated than a simple plane polygon, 
using node coordinates is really not a valuable option.

In short, in real life applications, a mesh without boundary and subdomain 
markers is of very little use.

c.

reply via email to

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