The error message I obtain is the following :

Div_uv.Test_pv
^
Divergence operator can only be applied toFields with qdim (1) equal to dim (3)

logic_error exception caught
Error using gf_matlab
Error in ../../src/getfem_generic_assembly_semantic.cc, line 1896 :
Error in assembly string


The diverence operator is in fact only defined in 3D for 3D vector fields. This is the problem. I think you can use instead Grad_uv which gives the gradient of the quantity on the elements under the form of a tangent vector. Another tangent vector can be obtained with element_K but which is sensitive with the orientation of the element (this can cause some problems). So, may be, your rewrite your expressions as

'(Grad_uv.Normalized(element_K))*Test_pv'

and the second expression by

'-pv*(Grad_Test_uv.Normalized(element_K))'

Best regards,

Yves


Le 04/12/2019 à 13:11, Davide Manfredo a écrit :
%% Lambda

nbsk=10;                                        %Number of nodes over each branch of my Y-shaped mesh
nbranches=3;                                 %Number of branches
Lambda=zeros(nbranches,nbsk,3);                 %For simplicity, we have 3 branches, each one with the same number of nodes Lambda(1,:,1)= linspace(0+eps,0.5,nbsk);  %Lambda=Lambda(#branch, #nodes, x-y-z coordinates)
Lambda(1,:,2)= linspace(0.5,0.5,nbsk);
Lambda(1,:,3)= linspace(0.5,0.5,nbsk);


Lambda(2,:,1)= linspace(0.5,1,nbsk);
Lambda(2,:,2)= linspace(0.5,1,nbsk);
Lambda(2,:,3)= linspace(0.5,0.5,nbsk);


Lambda(3,:,1)= linspace(0.5,1,nbsk);
Lambda(3,:,2)= linspace(0.5,0,nbsk);
Lambda(3,:,3)= linspace(0.5,1,nbsk);


LambdaM=gf_mesh('empty',3);                %Define an empty mesh

for nb=1:nbranches
    gf_mesh_set(LambdaM, 'add point', squeeze(Lambda(nb,:,:))');  %add every single point to my mesh
end

GT=gf_geotrans('GT_PK(1,1)');             %create a geometric transformation over the mesh in order to define convexes (segment) over my mesh

nbpts=gf_mesh_get(LambdaM,'nbpts');

for nb=1:nbranches
    for n=1:nbsk-1
        gf_mesh_set(LambdaM, 'add convex', GT, squeeze(Lambda(nb,[n,n+1],:))');     %add convexes to my mesh
    end
end

Over this mesh I have defined  the variable 'uv' whose FEM is 'FEM_PK(1,1)', and 'pv' whose FEM is 'FEM_PK_DISCONTINUOUS(1,0)'. Over these meshfem objects, I have defined two integration methods: mimLv for 'uv' and mimLp for 'pv', both using 'IM_GAUSS1D(1)'.
Now, the problem comes if I run these bricks
gf_model_set(md, 'add nonlinear generic assembly brick', mimLp,  'Div_uv.Test_pv', -1, 0, 0); gf_model_set(md, 'add nonlinear generic assembly brick', mimLv, '-pv.Div_Test_uv', -1, 0, 0);

I also tried to split my mesh in regions corresponding to the 3 different branches, but still, it doesn't work and I get the same error. I even proceeded with the gf_asm command, using 'generic', but it doesn't work.

What doesn't convince me is that other mass bricks or source term bricks work perfectly fine over the same mesh with the same variables, so now I'm really stuck.
Thank you very much for your support, I really appreciate it.

Best regards,
Davide Manfredo

On Tue, Dec 3, 2019 at 7:32 PM Yves Renard <[email protected] <mailto:[email protected]>> wrote:



    Dear  Davide,

    This is still not clear. Can you send us the minimal code that
    contains the error ?

    Best regards,

    Yves



    ----- Mail original -----
    De: "Davide Manfredo" <[email protected]
    <mailto:[email protected]>>
    À: "logari81" <[email protected]
    <mailto:[email protected]>>
    Cc: "getfem-users" <[email protected]
    <mailto:[email protected]>>
    Envoyé: Mardi 3 Décembre 2019 10:47:38
    Objet: Re: Error in assembly string, maybe due to mesh definition

    Goodmornig,

     Thank you for your reply, this is the output I get.

    Error using gf_matlab
    Error in getfem_generic_assembly.cc, line 9611 void
    getfem::ga_node_analysis(const string&, getfem::ga_tree&,
    const getfem::ga_workspace&, getfem::pga_tree_node,
    bgeot::size_type, bgeot::size_type, bool, bool, int):
    Error in assembly string

    Error in gf_model_set (line 1381)
        gf_matlab('model_set', varargin{:});

    Error in Branches (line 270)
        gf_model_set(md, 'add nonlinear generic assembly
        brick', mimLp,  'Div_uv.Test_pv', -1, 0, 0) %Dvv

    Best regards,
    Davide

    On Tue, Dec 3, 2019 at 9:03 AM Konstantinos Poulios
    <[email protected] <mailto:[email protected]>>
    wrote:

    > Hi,
    >
    > Could you also share the whole output before and after the "error in
    > assembly string" message?
    >
    > BR
    > Kostas
    >
    > On Fri, Nov 29, 2019 at 1:31 PM Davide Manfredo
    <[email protected] <mailto:[email protected]>>
    > wrote:
    >
    >> Dear Getfem++ Users,
    >>
    >> I have the following bricks, in my assembled and working
    matrix, using
    >> MATLAB Interface
    >>
    >> gf_model_set (md, 'add nonlinear generic assembly brick', mimLp,
    >> 'Div_uv.Test_pv', -1, 0, 0);
    >> gf_model_set (md, 'add nonlinear generic assembly brick', mimLv,
    >> '-pv.Div_Test_uv', -1, 0, 0);
    >>
    >> where uv and pv are two of the four unknowns of the system, and
    the mesh
    >> is a straight segment LambdaM defined as follows
    >> Lambdaref= 0:1/(nbsk-1):1;
    >> LambdaM=gf_mesh('cartesian', Lambdaref);
    >>
    >> and mimLp and mimLv are the integration methods for uv and pv
    >> respectively over LambdaM.
    >> uv is approximated by 'FEM_PK(1,1)'
    >> pv is approximated by 'FEM_PK_DISCONTINUOUS(1,0)'
    >>
    >> This is running properly, my problem starts when I modify the mesh.
    >> In fact, I tried to define an empty mesh to which I added
    geometrical
    >> properties and points one by one, in the following way
    >>
    >> LambdaM=gf_mesh('empty',3);  %Here Lambda is of dimension 3
    because it's
    >> supposed to be a segment embedded in a 3D domain
    >> gf_mesh_set(LambdaM, 'add point', [point vect]);
    >> GT=gf_geotrans('GT_PK(1,1)');
    >>
    >> Running the same codes as above I received the error "error in
    assembly
    >> string".
    >> Do you have any idea what the problem could be? I think that
    the problem
    >> lies in the mesh definition, but I can't see where specifically
    since other
    >> bricks work perfectly and with the other mesh definition I
    didn't have any
    >> problem.
    >>
    >> Thank you very much for your support,
    >> Davide Manfredo
    >>
    >

Reply via email to