Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: cyril cassisa <ccassisa@gm...>  20120221 09:31:08

Hi everyone, I am working on other BSpline functions called Regular CurvedKnot BSpline (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 BSpline 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. PostDoc INRIA 
From: c. <carlo.defalco@gm...>  20120221 13:44:17

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 tensorproduct based classes and their specific methods (those with neame ending in _tp). > *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 ?* just because no one never implemented it, I don't see why it should not work to derive a class for spaces, actually I think it has already been done by someone at EPFL > 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. > PostDoc INRIA 
From: Rafael Vazquez <vazquez@im...>  20120221 18:04:41

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 tensorproduct 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 
From: cyril cassisa <ccassisa@gm...>  20120305 10:20:13

Good morning, I come back to you to have your advises on changing the BSpline 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 BSpline 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 <vazquez@...>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 > tensorproduct 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/learndevnowd2d > _______________________________________________ > Geopdesusers mailing list > Geopdesusers@... > https://lists.sourceforge.net/lists/listinfo/geopdesusers > Rafael Vazquez vazquez@... via<http://support.google.com/mail/bin/answer.py?hl=en&ctx=mail&answer=1311182>; lists.sourceforge.net Feb 22 (13 days ago) to geopdesusers 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 BSpline functions called Regular CurvedKnot > BSpline (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 BSpline 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. > PostDoc INRIA > 
From: Dede' Luca <luca.dede@ep...>  20120221 13:59:09

Dear all, > > *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 ?* > > just because no one never implemented it, I don't see why it should not work to derive a class for spaces, > actually I think it has already been done by someone at EPFL Yes, a student did an attempt for a scalar PDE defined on a surface. It is relatively easy to implement it by using the existing functions as a starting point. We did not submit our contribution because the implementation was very much 'ad hoc'. Best regards, Luca Dede'  Luca DEDE', Dott.Ing., PhD Researcher, Lecturer EDMA CMCS  Chair of Modeling and Scientific Computing MATHICSE  Mathematics Institute of Computational Science and Engineering EPFL  Ecole Polytechnique Federale de Lausanne Office: MA C2 557, Av. Piccard, Station 8, CH1015 Lausanne, Switzerland Phone: +41 21 693 0318 Fax: +41 21 693 5510 Email: luca.dede@... Web: http://sma.epfl.ch/~dede/  ________________________________________ From: c. [carlo.defalco@...] Sent: Tuesday, February 21, 2012 2:43 PM To: cyril cassisa Cc: Geopdesusers@... Subject: Re: [Geopdesusers] Replacing Nurbs with CurvedKnot BSpline in GeoPDEs 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 tensorproduct based classes and their specific methods (those with neame ending in _tp). > *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 ?* just because no one never implemented it, I don't see why it should not work to derive a class for spaces, actually I think it has already been done by someone at EPFL > 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. > PostDoc INRIA  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/learndevnowd2d _______________________________________________ Geopdesusers mailing list Geopdesusers@... https://lists.sourceforge.net/lists/listinfo/geopdesusers 
From: Rafael Vazquez <vazquez@im...>  20120221 17:37:32

Dear all, Il 21/02/2012 14:58, Dede' Luca ha scritto: > Dear all, > > >> > *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 ?* >> >> just because no one never implemented it, I don't see why it should not work to derive a class for spaces, >> actually I think it has already been done by someone at EPFL >> > Yes, a student did an attempt for a scalar PDE defined on a surface. It is relatively easy to implement it by using the existing functions as a starting point. We did not submit our contribution because the implementation was very much 'ad hoc'. > > In fact, a couple of people asked me the same thing before, and I think this could be an interesting contribution. Luca, it would be great if you (or your student) could find the time to prepare the simplest example. Regards, Rafa 
From: cyril cassisa <ccassisa@gm...>  20120221 15:27:29

Thanks for your fast answers. For the surface in 3D, I see that it is quite easy to change the actual toolbox. Thanks for the advices for the modification I have to make for the geometric function. I will skip the tensorproduct based classes and their specific methods but I will have to modify all function related to knots vectors. I will inform you later about the advancement of my work. Sincerely Cyril Cassisa On Tue, Feb 21, 2012 at 9:58 PM, Dede' Luca <luca.dede@...> wrote: > Dear all, > > > > *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 ?* > > > > just because no one never implemented it, I don't see why it should > not work to derive a class for spaces, > > actually I think it has already been done by someone at EPFL > > Yes, a student did an attempt for a scalar PDE defined on a surface. It is > relatively easy to implement it by using the existing functions as a > starting point. We did not submit our contribution because the > implementation was very much 'ad hoc'. > > Best regards, > > Luca Dede' > > > >  > Luca DEDE', Dott.Ing., PhD > > Researcher, Lecturer EDMA > CMCS  Chair of Modeling and Scientific Computing > MATHICSE  Mathematics Institute of Computational Science and Engineering > EPFL  Ecole Polytechnique Federale de Lausanne > > Office: MA C2 557, Av. Piccard, Station 8, CH1015 Lausanne, Switzerland > Phone: +41 21 693 0318 > Fax: +41 21 693 5510 > Email: luca.dede@... > Web: http://sma.epfl.ch/~dede/ > >  > > ________________________________________ > From: c. [carlo.defalco@...] > Sent: Tuesday, February 21, 2012 2:43 PM > To: cyril cassisa > Cc: Geopdesusers@... > Subject: Re: [Geopdesusers] Replacing Nurbs with CurvedKnot BSpline in > GeoPDEs > > 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 > tensorproduct based classes and their > specific methods (those with neame ending in _tp). > > > *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 ?* > > just because no one never implemented it, I don't see why it should not > work to derive a class for spaces, > actually I think it has already been done by someone at EPFL > > > 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. > > PostDoc INRIA > > > > >  > 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/learndevnowd2d > _______________________________________________ > Geopdesusers mailing list > Geopdesusers@... > https://lists.sourceforge.net/lists/listinfo/geopdesusers > 
From: c. <carlo.defalco@gm...>  20120221 16:13:07

On 21 Feb 2012, at 20:57, cyril cassisa wrote: > I will skip the tensorproduct based classes and their specific methods but I will have to modify all function related to knots vectors. Yes, the nurbs toolbox is really quite specific for nurbs and bsplines so there is quite a few functions you will have to replace there. For an example of using different knot vectors for different functions you might want to have a look at the function tbasisfun: http://octave.svn.sourceforge.net/viewvc/octave/trunk/octaveforge/extra/nurbs/inst/tbasisfun.m?view=log c. 
From: Rafael Vazquez <vazquez@im...>  20120221 17:57:08

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 BSpline functions called Regular CurvedKnot > BSpline (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 BSpline 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. > PostDoc INRIA > 
From: Rafael Vazquez <vazquez@im...>  20120305 14:43:44

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 BSpline > 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 BSpline 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 Bsplines, 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 Bspline 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 nonhomogeneous 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. > 
From: cyril cassisa <ccassisa@gm...>  20120309 10:02:22

I incorporate the new BSpline 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@...>wrote: > ** > 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 BSpline > 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 BSpline 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 Bsplines, 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 Bspline 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 nonhomogeneous 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. > > > 
From: c. <carlo.defalco@gm...>  20120309 10:53:38

On 9 Mar 2012, at 11:02, cyril cassisa wrote: > 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). I am not sure what exactly you mean, but please be aware that quadrature in geopdes is always done in the physical space rather than in the reference space. So what you need is to construct weights and nodes for a quadrature rule on your surface. Quadrature on bivariate surfaces in 3d is already used to apply pressure boundary conditions in geopdes_elasticty, to achieve this the method sp_eval_boundary_side from the class sp_vector_3d constructs quadrature nodes and weights on the boundary of a 3d patch, you could use the code in there as inspiration. Hope this helps, Carlo 
From: Rafael Vazquez <vazquez@im...>  20120309 11:40:23

Dear Cyril, I agree with Carlo. The implementation for a surface in 3D should be very similar to what is already done for the boundary of the volumes. Take a look at the function sp_eval_boundary_side (also in the scalar case), and at the section 3 of the report, where we also give some explanations about the boundary. Regards, Rafa Il 09/03/2012 11:53, c. ha scritto: > On 9 Mar 2012, at 11:02, cyril cassisa wrote: > > >> 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). >> > I am not sure what exactly you mean, but please be aware that quadrature in geopdes is always done > in the physical space rather than in the reference space. > So what you need is to construct weights and nodes for a quadrature rule on your surface. > Quadrature on bivariate surfaces in 3d is already used to apply pressure boundary conditions in geopdes_elasticty, > to achieve this the method sp_eval_boundary_side from the class sp_vector_3d constructs quadrature nodes and weights > on the boundary of a 3d patch, you could use the code in there as inspiration. > > Hope this helps, > Carlo 
Sign up for the SourceForge newsletter:
No, thanks