[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.
- Re: blog update #2, (continued)
- Re: blog update #2, c., 2013/06/17
- Re: blog update #2, c., 2013/06/17
- RE: blog update #2, Marco Vassallo, 2013/06/17
- Re: blog update #2, c., 2013/06/17
- RE: blog update #2, Marco Vassallo, 2013/06/18
- Re: blog update #2, c., 2013/06/18
- RE: blog update #2, Marco Vassallo, 2013/06/18
- Re: blog update #2, c., 2013/06/18
- RE: blog update #2, Marco Vassallo, 2013/06/18
- RE: blog update #2, Marco Vassallo, 2013/06/19
- Re: blog update #2,
c. <=
- Re: blog update #2, c., 2013/06/14
- RE: blog update #2, Marco Vassallo, 2013/06/15