I incorporate the new B-Spline function in the geoPDEs toolbox.
Results are not so good for the moment because I made many approximation in
the code.
First, before looking more deeply in what is wrong in my implementation.
I want to adapt the GeoPDEs toolbox to be able to treat problems on 3D
surfaces.
With only a parametrization in 2D U and V representing a surface in 3D in
x,y,z.
Today I got to the problem that the function *F *from (U,V) to (x,y,z) is
now a 2x3 matrix.
*Quadrature points* are in 2d (u,v)
*msh *class the variable *geo_map *and *geo_map_der (jacobien) *is 2x3.
We have then to compute the determinant and inverse and also make a product
of *geo_map_der **(jacobien) ** *with *space *class variable
*shape_function_gradients
*which is of size 2 in domain (u,v).
*What is the better solution to modify the code ?*
I chose to modif the msh_2d and sp_nurbs_2d (bspline).
To get a 3x3 matrix for *geo_map_der **(jacobien) **. *The 2 first lines
represent the 2 tangent vectors. I add a 3rd line by computing the normal
vector by vectorial product of the 2 tangent vectors. Then I got an
inversible matrix, compute determinant and inverse.
For the product with *shape_function_gradients *, I add a virtual line to
compute it with the inversed 3x3 Jacobien matrix. Then I suppress the added
line after computation.
Results I obtain on the laplace equation examples, seem to be correct if
the 3D surface is in the plan (Oxy) (i.e z constant).
But the geomerty is in complete 3d, it seems to have some problem then.
Hope my mail is clear enough.
Don't hesitate to give me your advices. They are very helpful.
I remember in previous email that you have already one people working on
the extension on the 3d surface defining by 2d parametric domain. Is it
possible to have his contact, to exchange with him directly ?
Thank you very much.
Cyril
On Mon, Mar 5, 2012 at 10:43 PM, Rafael Vazquez <vazquez@...:
> **
> Dear Cyril,
> I reply below.
>
> Regards,
> Rafa
>
> Il 05/03/2012 11:20, cyril cassisa ha scritto:
>
> 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 ?*
>
> Yes, I think so. Since your space of functions is different you will have
> to create a different space class.
>
>
> 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 ?*
>
> Yes, and I think you should use them. Using *nqn_dir* is better for
> tensor product spaces, but in your case using quad_nodes seems the best
> choice.
>
> 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 ?
>
> Yes, I think so. Since *ndof*, *nsh* and *connectivity* are the same that
> for B-splines, you can keep that part, both in SP_BSPLINE_1D_PARAM and in
> SP_EVALUATE_COL_PARAM. And since your space is not tensor product, I think
> it doesn't make any sense to compute the *shape_functions* in the 1D
> spaces. You will need to add the functions to compute them.
>
> As a first idea you could use something similar to *tbasisfun*, the
> function that Carlo told you the other day. It computes a B-spline basis
> function in a set of given points. In your case I think it would be more
> efficient to compute several basis functions at a single point, but in any
> case you need a function to compute them. The rest is simply reordering the
> information in an array with the right size.
>
> And if you are planning to solve problems with non-homogeneous boundary
> conditions, probably you will need to change SP_EVAL_BOUNDARY_SIDE. Right
> now the knot vector is the same for the opposite sides.
>
>
>
> 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.
>
>
>
|