getfem-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Error in assembly string, maybe due to mesh definition


From: Yves Renard
Subject: Re: Error in assembly string, maybe due to mesh definition
Date: Wed, 4 Dec 2019 14:44:32 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1

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 <address@hidden> 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" <address@hidden>
À: "logari81" <address@hidden>
Cc: "getfem-users" <address@hidden>
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 <address@hidden>
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 <address@hidden>
> 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

[Prev in Thread] Current Thread [Next in Thread]