Re: [Geopdes-users] Replacing Nurbs with Curved-Knot B-Spline in GeoPDEs

[cyril c. <cca...@gm...>]

Good morning,

I come back to you to have your advises on changing the B-Spline function
type in GeoPDEs.
I already correctly changed the geometry structure and mesh class.
I am now attaquing the last one, the space class. However it seems to be
the most important and the most complex to adapt.

What I understand is that you precompute the basis function value for the
quadrature point on each direction in variables
-  *shape_functions   *and   *shape_function_gradients *(depending to what
you need)

In case of NURBS or B-Spline the knot vector in U and V direction stay the
same over the domain and the quadrature points don't change parametric
coordinates. So it is easy to compute the basis functions and derivatives
on each direction in one time for all.

In my case, Uknot is function of parametric coordinate v which change the
Uknot vector over the parametric domain. Basis functions changes, as well
as quadrature points parametric coordinates.
So, the first thing I understand is that I should change quite a lot the *space
*class to adapt it to a varying knot parametric domain.
*Do you think is the only way ?*

When you compute the *shape_functions   *and   *shape_function_gradients*,
you do not use the information of quadrature points parametric coordinates
contained in the msh class (*quad_nodes*), but you only use *nqn_dir *which
is sufficient if it is constant over the domain.
*Do you think I can use quad_nodes ?*
Then I can know the value of 'v' for the current quadrature point and then
compute the corresponding Uknot vector at this quadrature point, the basis
function and its derivatives.

In space classes, for the other variables, I think it is OK and does not
need to be changed. Even if my parametric domain is varying, I still get
same number of element in U and V direction, same number of quadrature
points, same degrees of freedom and same indices of basis functions that do
not vanish in each element.

So my work should focus on SP_NURBS_2D, SP_EVALUATE_COL_PARAM and
SP_BSPLINE_1D_PARAM, is it right ?

Thank you very much for your time and your help.
It is of a great use, cause I become to be too much inside GeoPDEs codes
and afraid to mix things.

Regards,

Cyril Cassisa.


On Wed, Feb 22, 2012 at 2:04 AM, Rafael Vazquez <va...@im...>wrote:

> Il 21/02/2012 14:43, c. ha scritto:
> > On 21 Feb 2012, at 15:00, cyril cassisa wrote:
> >
> >
> >
> >> *Do you think that I am going on a big complex mess ? or do you think it
> >> will be only simple modifications ?*
> >>
> > I think it shouldn't be a big problem if you just skip all the
> tensor-product based classes and their
> > specific methods (those with neame ending in _tp).
> >
> >
> Yes, I agree that it is better to start without the _tp functions. Maybe
> in a second step you can use some of the ideas there, but I don't
> recommend to use them for now.
>
> Rafa
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Geopdes-users mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geopdes-users
>


Rafael Vazquez va...@im...
via<http://support.google.com/mail/bin/answer.py?hl=en&ctx=mail&answer=1311182>
 lists.sourceforge.net
Feb 22 (13 days ago)
to geopdes-users
Dear Cyril,
from your explanation I understand that you have defined the structure,
but not the functions to work with it. The most important thing is to
write the functions to evaluate the basis functions (and derivatives) at
some points, and to evaluate the parametrization (and derivatives) of
your domain. Kind of a RCKBS toolbox. Once you have this toolbox,
computing the space shouldn't give you any trouble.

And as you said, you also have to change the quadrature rule. For this
you must decide which are the quadrature points in the curved elements
of the parametric domain, and give a function to compute them, but the
fields of the msh structure should remain basically the same.

Regards,
Rafa

Il 21/02/2012 10:30, cyril cassisa ha scritto:
> Hi everyone,
>
> I am working on other B-Spline functions called Regular Curved-Knot
> B-Spline (RCKBS).
> These functions are interesting for representing particular geometries
> (surfaces and volumes) for example it can deal with continuity variation
> over the domain.
> The parametric domain is then not a regular grid as for B-Spline and
Nurbs.
>
> I am trying to incorporate RCKBS in GeoPDEs toolbox. But I encounter some
> difficulties.
> For that I create a new structure RCKBS using the same style as NURBS
> structure.
> Then I see that I also have to modify the mesh stucture.
> Because in the case of RCKBS, the knot vector varies over the parametric
> domain. For example for a surface:
> - Uknot(v): Uknot is function of the v direction
> - Vknot(u): Vknot is function of the u direction
> Then I have a lowerbound and upperbound knot vectors for U and for V.
>
> I think that then, I will have to modify the quadratic rule computation as
> my parametric domain is not regular on u and v direction, modify the msh
> and space as well.
> *Do you think that I am going on a big complex mess ? or do you think it
> will be only simple modifications ?*
>
> I have also another question about the GeoPDEs toolbox.
> For surfaces you consider that we are necessarily in 2D and volume is for
> 3D.
> *Why does GeoPDEs cannot deal with 3D surfaces meaning that the physical
> points are in 3d space but knots are only on U and V directions ?*

> I try to consider my 3D surface as a volume with no depth but I got some
> bugs then from boundary condition problem (I think).
>
> Thank you very much for your help.
> Thanks to GeoPDEs developpers. It is very nice to have access to an open
> source IGA toolbox.
> Hope I will be able to bring my contribution on it.
>
> Sincerely
>
> Cyril Cassisa.
> Post-Doc INRIA
>