You can subscribe to this list here.
2010 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(1) 
_{Nov}
(1) 
_{Dec}


2011 
_{Jan}

_{Feb}

_{Mar}
(1) 
_{Apr}

_{May}
(1) 
_{Jun}
(9) 
_{Jul}
(2) 
_{Aug}
(6) 
_{Sep}
(11) 
_{Oct}
(15) 
_{Nov}
(4) 
_{Dec}
(9) 
2012 
_{Jan}
(7) 
_{Feb}
(14) 
_{Mar}
(11) 
_{Apr}

_{May}

_{Jun}
(3) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(3) 
_{Dec}

2013 
_{Jan}
(8) 
_{Feb}

_{Mar}
(1) 
_{Apr}
(3) 
_{May}

_{Jun}

_{Jul}
(3) 
_{Aug}
(2) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}
(4) 
2014 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}
(2) 
_{Jun}
(2) 
_{Jul}

_{Aug}

_{Sep}
(5) 
_{Oct}
(3) 
_{Nov}
(1) 
_{Dec}
(4) 
2015 
_{Jan}
(5) 
_{Feb}
(10) 
_{Mar}
(12) 
_{Apr}
(14) 
_{May}
(26) 
_{Jun}
(7) 
_{Jul}

_{Aug}

_{Sep}
(4) 
_{Oct}

_{Nov}

_{Dec}

2016 
_{Jan}
(1) 
_{Feb}
(9) 
_{Mar}
(3) 
_{Apr}
(3) 
_{May}
(12) 
_{Jun}
(2) 
_{Jul}
(8) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1

2

3

4

5

6
(2) 
7
(2) 
8

9

10

11

12
(2) 
13
(1) 
14

15

16
(2) 
17

18

19

20

21

22

23
(2) 
24

25

26
(2) 
27

28
(2) 
29

30

31






From: Rafael Vazquez <vazquez@im...>  20111028 10:46:07

Dear GeoPDEs users, our colleague Timo Lähivaara has written a package, based on GeoPDEs, to solve the acoustic wave equation in time domain, using a low storage RungeKutta method for the time discretization. The package contains some examples in the square geometry, and also an example with periodic boundary conditions. The package is available in the web page of the project, in the Contributions section. http://geopdes.sourforge.net Regards, Rafa 
From: Rafael Vazquez <vazquez@im...>  20111028 10:39:24

Dear GeoPDEs users, for some days I kept thinking about the krefinement. I think this is an interesting topic, so I send you a summary of what I did. First of all, Alexis was right about the krefinement. I misunderstood his code, and thought that he only had one element, but in fact he was using a 2x2 mesh. So the functions are not globally smooth, as I thought, and the continuity is important. Well, I asked a colleague to repeat the same test in his own code (thanks, Massimiliano). The results are the same, except for rounding errors (that grow with the degree), and the oscillations appear from a very low degree. At least it is clear that the problem is not a bug in the code. We have also tried increasing the number of elements, and the oscillations appear much later, or don't appear at all. The explanation comes from the theory. When doing h or prefinement, the error decreases at each refinement step, because the spaces are nested. But when doing krefinement, since you increase the degree and the continuity at the same time, the spaces are not nested, and nothing assures you that the error will be reduced. Numerically, krefinement seems to work better when the mesh is fine enough, and in this particular example, for coarse meshes, odd degree discretizations seem to work better than the even degree ones. Regards, Rafa 
From: Rafael Vazquez <vazquez@im...>  20111026 16:46:19

Hi Alexis, no, it is not enough. You need a parameterization of the whole domain, and this means that you must also give the interior control points. Moreover, there are some papers showing that the solution depends a lot on the parameterization, so this points must be chosen carefully. Rafa Il 26/10/2011 12:53, alexis papagiannopoulos ha scritto: > dear geopde users, > > When constructing a 2D or a 3D domain with the NURBS toolbox ,does it > suffice to give boundary data control points? > > Alexis Papagiannopoulos >  > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@... SelfAssessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/ciscodev2dev > _______________________________________________ > Geopdesusers mailing list > Geopdesusers@... > https://lists.sourceforge.net/lists/listinfo/geopdesusers > 
From: alexis papagiannopoulos <alexis.papagiannopoulos@gm...>  20111026 10:53:27

dear geopde users, When constructing a 2D or a 3D domain with the NURBS toolbox ,does it suffice to give boundary data control points? Alexis Papagiannopoulos 
From: Rafael Vázquez <vazquez@im...>  20111023 17:43:08

Hi Alexis, it works exactly as for finite elements. First you set all the degrees of freedom related to the Dirichlet boundary, and then you solve the system for all the others, that are the interior ones. Something like this: drchlt_dofs = union (drchlt_dofs1, drchlt_dofs2); int_dofs = setdiff (1:space.ndof, drchlt_dofs); rhs(int_dofs) = rhs(int_dofs)  mat(int_dofs, drchlt_dofs) * u(drchlt_dofs); u(int_dofs) = mat(int_dofs, int_dofs) \ rhs(int_dofs); And since you are using the L2projection to impose the Dirichlet condition, you can use the function sp_drchlt_l2_proj also for several sides. It is enough to define the boundary function with a switch, as it is done for instance in test_cube_g_nmnn for the Neumann condition. Rafa 
From: alexis papagiannopoulos <alexis.papagiannopoulos@gm...>  20111023 11:46:28

Dear GEOpdes users, I am trying to solve the following BVP on a 3D domain(attached file), where the bottom and top sides are dichlet boundaries(u=1 and u=0) and the other sides are subjected to neumann conditions. drchlt_side1 = [ 5]; drchlt_side2=[6]; nmnn_sides = [1 2 3 4]; rhs = zeros (space.ndof, 1); for iside = nmnn_sides msh_side = msh_eval_boundary_side (msh, iside); sp_side = sp_eval_boundary_side (space, msh_side); x = squeeze (msh_side.geo_map(1,:,:)); y = squeeze (msh_side.geo_map(2,:,:)); z = squeeze (msh_side.geo_map(3,:,:)); gval = zeros(size(x)); rhs_loc = op_f_v (sp_side, msh_side, gval); rhs(sp_side.dofs) = rhs(sp_side.dofs) + rhs_loc; end drchlt_dofs1 = []; for iside = 1:numel (drchlt_side1) drchlt_dofs1 = union (drchlt_dofs1, space.boundary(drchlt_side1(iside)).dofs); end int_dofs1 = setdiff (1:space.ndof, drchlt_dofs1); drchlt_dofs2 = []; for iside = 1:numel (drchlt_side2) drchlt_dofs2 = union (drchlt_dofs2, space.boundary(drchlt_side2(iside)).dofs); end int_dofs2 = setdiff (1:space.ndof, drchlt_dofs2); M_drchlt1 = spalloc (space.ndof, space.ndof, space.ndof); rhs_drchlt1 = zeros (space.ndof, 1); for iside = drchlt_side1 msh_bnd = msh_eval_boundary_side (msh, iside); sp_bnd = sp_eval_boundary_side (space, msh_bnd); x = squeeze (msh_bnd.geo_map(1,:,:)); y = squeeze (msh_bnd.geo_map(2,:,:)); z=squeeze(msh_bnd.geo_map(3,:,:)); hval = ones(size(x)); M_side1 = op_u_v (sp_bnd, sp_bnd, msh_bnd, ones (size(x))); M_drchlt1(sp_bnd.dofs, sp_bnd.dofs) = M_drchlt1(sp_bnd.dofs, sp_bnd.dofs) + M_side1; rhs_side1 = op_f_v (sp_bnd, msh_bnd, hval); rhs_drchlt1(sp_bnd.dofs) = rhs_drchlt1(sp_bnd.dofs) + rhs_side1; end M_drchlt2 = spalloc (space.ndof, space.ndof, space.ndof); rhs_drchlt2 = zeros (space.ndof, 1); for iside = drchlt_side2 msh_bnd = msh_eval_boundary_side (msh, iside); sp_bnd = sp_eval_boundary_side (space, msh_bnd); x = squeeze (msh_bnd.geo_map(1,:,:)); y = squeeze (msh_bnd.geo_map(2,:,:)); z=squeeze(msh_bnd.geo_map(3,:,:)); hval = zeros(size(x)); M_side2= op_u_v (sp_bnd, sp_bnd, msh_bnd, ones (size(x))); M_drchlt2(sp_bnd.dofs, sp_bnd.dofs) = M_drchlt2(sp_bnd.dofs, sp_bnd.dofs) + M_side2; rhs_side2 = op_f_v (sp_bnd, msh_bnd, hval); rhs_drchlt2(sp_bnd.dofs) = rhs_drchlt2(sp_bnd.dofs) + rhs_side2; end u = zeros (space.ndof, 1); u(drchlt_dofs1) = M_drchlt1(drchlt_dofs1, drchlt_dofs1) \ rhs_drchlt1(drchlt_dofs1); rhs(int_dofs1) = rhs(int_dofs1)  mat(int_dofs1, drchlt_dofs1) * ... u(drchlt_dofs1); u(int_dofs1) = mat(int_dofs1, int_dofs1) \ rhs(int_dofs1); u(drchlt_dofs2) = M_drchlt2(drchlt_dofs2, drchlt_dofs2) \ rhs_drchlt2(drchlt_dofs1); rhs(int_dofs2) = rhs(int_dofs2)  mat(int_dofs2, drchlt_dofs2) * ... u(drchlt_dofs2); u(int_dofs2) = mat(int_dofs2, int_dofs2) \ rhs(int_dofs2); Is this the right way to implement my boundary conditions.I am more or less worried abount the seperation of internal dofs and drchlt dofs since now different dirichlet conditions are applied to different sides. Thank you, Alexis Papagiannopoulos 
From: c. <carlo.defalco@gm...>  20111016 11:04:27

On 16 Oct 2011, at 12:37, Jahanshahi, Mohsen wrote: > Dear GeoPDEs Users, > > I have successfully installed geopdes_base under WindowsXP operating > system. But it seems that some functions such as msh_2d_tensor_product are > missing from the package. Am I right? > > Best Regards > > Mohsen Mohsen, Yes, that function is missing but it is not a bug, that is a change in the API from geopdes release 1.x and 2.x differences in the two versions are documented in appendix C of the report which you can downlod from here: http://sourceforge.net/projects/geopdes/files/GeoPDEs_report.pdf HTH, Carlo 
From: Jahanshahi, Mohsen <info@ja...>  20111016 10:53:21

Dear GeoPDEs Users, I have successfully installed geopdes_base under WindowsXP operating system. But it seems that some functions such as msh_2d_tensor_product are missing from the package. Am I right? Best Regards Mohsen 
From: Rafael Vazquez <vazquez@im...>  20111013 08:28:30

Hi Alexis, I've tried to do the same modifying the file ex_laplace_iso_ring (see below). The oscillations appear around degree 17, that is much higher than what you usually do in IGA. The first thing I must say is that this shouldn't be considered krefinement: you have only one element, and the continuity is not playing any role. What you are doing is some kind of spectral method with NURBS. You can try to read some works on spectral methods (I'm not an expert) and check if they need some special technique to obtain the right convergence, maybe a particular quadrature rule. But I'm also thinking that the error may come from the NURBS toolbox. I know that some functions in the toolbox will add rounding errors to the computation of the shape functions, and I guess that these errors become much higher for high degrees. Since I've always worked with degree lower than 8, I never had any problem with this. You can check if the problem is coming from there. Regards, Rafa The problem_data is taken from ex_laplace_iso_ring. The postprocessing part is removed. The method data and the call to the solver are like this method_data.nsub = [1 1]; % In this example, this is only one element! for ii = 2:20 method_data.degree = [ii ii]; method_data.regularity = [ii1 ii1]; method_data.nquad = [ii+1 ii+1]; [geometry, msh, space, u] = solve_laplace_2d_iso (problem_data, method_data); [error_h1(ii), error_l2(ii)] = ... sp_h1_error (space, msh, u, problem_data.uex, problem_data.graduex); ndofs(ii) = space.ndof; end loglog(ndofs, error_l2); 
From: alexis papagiannopoulos <alexis.papagiannopoulos@gm...>  20111012 11:49:14

Dear geopdesusers, I tried to test some convergenece rates by applying several refinement strategies such krefinement and h refinement.Although h refinement has relatively a smooth convergence , krefinement presents a lot of oscillations .After creating a krefinement m file as such: function geo = krefinement( geo,degr,knts) nurbs=geo.nurbs; degelev=max(degr(nurbs.order1),0); nurbs=nrbdegelev(nurbs,degelev); [rknots,zeta,nknots]=kntrefine(nurbs.knots,knts,nurbs.order1,nurbs.order2); nurbs=nrbkntins(nurbs,nknots); geo=geo_load(nurbs); end I then apply homo_kerror.m to the 'geo_ring.txt' domain function errors = homo_kerror(geometry,i ) errors=[]; for j=1:1:i [dofs(1) errors(1)] = homo_poisson( geometry ); refined_geo(j)=krefinement(geometry,[j j],[1 1]); [dofs(j+1) errors(j+1)]=homo_poisson(refined_geo(j)); [dofs3(1) errors3(1)] = homo_poisson( geometry ); refined_geo2(j)=hrefinement(geometry,[j j]); [dofs2(j+1) errors2(j+1)]=homo_poisson(refined_geo2(j)); end loglog(dofs,errors,'ko',dofs2,errors2,'go') legend('krefinement','hrefinement') xlabel('dofs'); ylabel('error'); grid on end where homo_poisson.m is the problem presented in the geopdes report (article 4.1) function [dofs ,err] = homo_poisson( geometry ) nurbs=geometry.nurbs; geometry=geo_load(nurbs); knots = geometry.nurbs.knots; [qn, qw] = msh_set_quad_nodes (knots, msh_gauss_nodes (geometry.nurbs.order)); msh = msh_2d (knots, qn, qw, geometry); space = sp_nurbs_2d (geometry.nurbs, msh); dofs=space.ndof; mat = op_gradu_gradv_tp (space, space, msh, @(x, y) ones (size (x))); rhs = op_f_v_tp (space, msh, @(x, y) (89*sqrt(x.^2+y.^2)).*sin(2*atan(y./x))./(x.^2+y.^2)); drchlt_dofs = []; for iside = 1:4 drchlt_dofs = union (drchlt_dofs, space.boundary(iside).dofs); end int_dofs = setdiff (1:space.ndof, drchlt_dofs); u = zeros (space.ndof, 1); u(int_dofs) = mat(int_dofs, int_dofs) \ rhs(int_dofs); sp_to_vtk (u, space, geometry, [20 20], 'laplace_solution.vts', 'u') err = sp_l2_error (space, msh, u, @(x,y)(x.^2+y.^23*sqrt(x.^2+y.^2)+2).*sin(2.*atan(y./x))) end I tried several domains and problems and I get similar results. In krefinement the order elevates by 1 and then a new knot is inserted(in both directions) at each step. any suggestions why this occurs? Thank you, Alexis Papagiannopoulos 
From: Rafael Vazquez <vazquez@im...>  20111012 10:06:33

Dear GeoPDEs users, I realize that installing the Octave packages in Windows may cause a lot of trouble. For this reason, I write below the procedure I followed to install geopdes_base in Windows XP, and that worked for me (and for Yeo). I hope this will be helpful. Regards, Rafa INSTRUCTIONS TO INSTALL THE OCTAVE PACKAGES IN WINDOWS 1. Put the files nurbs<version>.tar.gz and geopdes_base<version>.tar.gz in a folder without blanks, for instance c:\tmp 2. In Octave, set the folder where to install the packages, typing the following mkdir c:\octavepackages pkg prefix c:\octavepackages c:\octavepackages 3. Install the nurbs package cd c:\tmp pkg install nurbs<version>.tar.gz pkg load nurbs 4. Uncompress and install the geopdes_base package system ("tar xzf geopdes_base<version>.tar.gz) pkg install geopdes_base If you get an error in step 4, try to download the mingwbased binary package, and replace the instructions in step 4 with: pkg install geopdes_base<version>mingw.tar.gz The mingwbased binary package is available here: http://sourceforge.net/projects/geopdes/files/Octave%20packages%20for%20Windows/ 
From: Rafael Vazquez <vazquez@im...>  20111007 16:33:59

Hello Yeo, about installing the package in Windows XP, I have seen that it doesn't work if the file geopdes_base<version>.tar.gz is in the folder c:\octavepackages. I think that the best thing is to put the file in a temporary folder, and to install the package from there. Rafa Il 06/10/2011 17:53, wei hong yeo ha scritto: > Dear geopdesusers, > > I tried to follow the instruction given in "README", however, right from > beginning I have already faced some problem in installing the packages. > Below are the error msg that I received from Octave. > > Words that Highlighted in yellow colour are the errors that I received. > > octave3.2.4.exe:2> pkg install nurbs1.3.5.tar.gz > bspeval.cc:62: warning: ignoring #pragma omp parallel > bspeval.cc:67: warning: ignoring #pragma omp for > > octave3.2.4.exe:3> pkg load nurbs > > octave3.2.4.exe:4> pkg install geopdes_base2.0.0.tar.gz > op_f_v.cc:20:21: error: geopdes.h: No such file or directory > op_f_v.cc:22: error: expected constructor, destructor, or type conversion > before > '(' token > mingw32g++4.4.0dw2: op_f_v.o: No such file or directory > make: *** [op_f_v.oct] Error 1 > 'make' returned the following error: make: Entering directory > `/tmp/oct7/geopde > s_base/src' > mkoctfile IC:\DOCUME~1\yeowh\LOCALS~1\Temp\oct7\geopdes_base\inst\include > op_f > _v.cc > make: Leaving directory `/tmp/oct7/geopdes_base/src' > error: called from `pkg>configure_make' in file > C:\octavepackages\share\octave\ > 3.2.4\m\pkg\pkg.m near line 1253, column 2 > error: called from: > error: C:\octavepackages\share\octave\3.2.4\m\pkg\pkg.m at line 714, > column 5 > > error: C:\octavepackages\share\octave\3.2.4\m\pkg\pkg.m at line 287, > column 7 > > By the way, Im using WinXP OS. > > On the other hand, I would like to know where we suppose to place the files > like nurbs1.3.5.tar.gz and geopdes_base2.0.0.tar.gz? whether is > c:\octavepackages or c:\octavepackages\bin ? > > Hopefully someone can give me some idea about this. > > Thanks. > > Regards, > Yeo >  > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunkd2dcopy1 > _______________________________________________ > Geopdesusers mailing list > Geopdesusers@... > https://lists.sourceforge.net/lists/listinfo/geopdesusers > 
From: Rafael Vazquez <vazquez@im...>  20111007 16:27:57

Dear GeoPDEs users, we have fixed the bug (thanks, Carlo!) for the installation in Octave 3.2, which is the most common version in Windows. The fixed packages are available in the usual web page: http://geopdes.sourceforge.net If any of you still has any problem with the installation, just let us know. Rafa 
From: Rafael Vazquez <vazquez@im...>  20111006 16:23:43

Dear Yeo, we know there is a bug when installing geopdes with octave 3.2. We will try to fix it as soon as possible, and send an email to the list when it is available (few days, I hope). The files nurbs<version>.tar.gz and geopdes_base<version>.tar.gz are only for installation, and after that they are not needed anymore. To install them, they should be in the same folder where you are working in Octave (use "pwd" within Octave). I don't have so much experience with Octave on Windows, but I think you shouldn't put the .tar.gz in c:\octavepackages. And the two warnings that you get when installing the nurbs toolbox are not important. They only tell you that it will not try to do parallelization with openMP in the function bspeval. Regards, Rafa Il 06/10/2011 17:53, wei hong yeo ha scritto: > Dear geopdesusers, > > I tried to follow the instruction given in "README", however, right from > beginning I have already faced some problem in installing the packages. > Below are the error msg that I received from Octave. > > Words that Highlighted in yellow colour are the errors that I received. > > octave3.2.4.exe:2> pkg install nurbs1.3.5.tar.gz > bspeval.cc:62: warning: ignoring #pragma omp parallel > bspeval.cc:67: warning: ignoring #pragma omp for > > octave3.2.4.exe:3> pkg load nurbs > > octave3.2.4.exe:4> pkg install geopdes_base2.0.0.tar.gz > op_f_v.cc:20:21: error: geopdes.h: No such file or directory > op_f_v.cc:22: error: expected constructor, destructor, or type conversion > before > '(' token > mingw32g++4.4.0dw2: op_f_v.o: No such file or directory > make: *** [op_f_v.oct] Error 1 > 'make' returned the following error: make: Entering directory > `/tmp/oct7/geopde > s_base/src' > mkoctfile IC:\DOCUME~1\yeowh\LOCALS~1\Temp\oct7\geopdes_base\inst\include > op_f > _v.cc > make: Leaving directory `/tmp/oct7/geopdes_base/src' > error: called from `pkg>configure_make' in file > C:\octavepackages\share\octave\ > 3.2.4\m\pkg\pkg.m near line 1253, column 2 > error: called from: > error: C:\octavepackages\share\octave\3.2.4\m\pkg\pkg.m at line 714, > column 5 > > error: C:\octavepackages\share\octave\3.2.4\m\pkg\pkg.m at line 287, > column 7 > > By the way, Im using WinXP OS. > > On the other hand, I would like to know where we suppose to place the files > like nurbs1.3.5.tar.gz and geopdes_base2.0.0.tar.gz? whether is > c:\octavepackages or c:\octavepackages\bin ? > > Hopefully someone can give me some idea about this. > > Thanks. > > Regards, > Yeo >  > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunkd2dcopy1 > _______________________________________________ > Geopdesusers mailing list > Geopdesusers@... > https://lists.sourceforge.net/lists/listinfo/geopdesusers > 
From: wei hong yeo <whyeo2003@gm...>  20111006 15:53:49

Dear geopdesusers, I tried to follow the instruction given in "README", however, right from beginning I have already faced some problem in installing the packages. Below are the error msg that I received from Octave. Words that Highlighted in yellow colour are the errors that I received. octave3.2.4.exe:2> pkg install nurbs1.3.5.tar.gz bspeval.cc:62: warning: ignoring #pragma omp parallel bspeval.cc:67: warning: ignoring #pragma omp for octave3.2.4.exe:3> pkg load nurbs octave3.2.4.exe:4> pkg install geopdes_base2.0.0.tar.gz op_f_v.cc:20:21: error: geopdes.h: No such file or directory op_f_v.cc:22: error: expected constructor, destructor, or type conversion before '(' token mingw32g++4.4.0dw2: op_f_v.o: No such file or directory make: *** [op_f_v.oct] Error 1 'make' returned the following error: make: Entering directory `/tmp/oct7/geopde s_base/src' mkoctfile IC:\DOCUME~1\yeowh\LOCALS~1\Temp\oct7\geopdes_base\inst\include op_f _v.cc make: Leaving directory `/tmp/oct7/geopdes_base/src' error: called from `pkg>configure_make' in file C:\octavepackages\share\octave\ 3.2.4\m\pkg\pkg.m near line 1253, column 2 error: called from: error: C:\octavepackages\share\octave\3.2.4\m\pkg\pkg.m at line 714, column 5 error: C:\octavepackages\share\octave\3.2.4\m\pkg\pkg.m at line 287, column 7 By the way, Im using WinXP OS. On the other hand, I would like to know where we suppose to place the files like nurbs1.3.5.tar.gz and geopdes_base2.0.0.tar.gz? whether is c:\octavepackages or c:\octavepackages\bin ? Hopefully someone can give me some idea about this. Thanks. Regards, Yeo 