Hi David,

That would be great if we can get the fix merged into master.

One more question is, do you know whether is it allowed to use the mass matrix variable coefficient maps with 3D Tetrahedra meshes?  
For a 3D problem, I tried to manipulate on coefficients of mass matrices, using Nektar::StdRegions::VarCoeffMap with the StdRegions::eVarCoeffMass key. This worked fine for 2D problems, but does not work in 3D. It seems to me that the  StdRegions::eVarCoeffMass coefficients are ignored and all the coefficients are defaultly set to 1.0. Any suggestions?

Thanks,

Tengfei

 
From: David Moxey
Date: 2020-06-26 22:29
To: zhangtengfei@sjtu.edu.cn
CC: nektar-users
Subject: Re: [Nektar-users] Formation of the global linear system
Hi Tengfei,
 
No problem. Thanks for testing, I'll get this patched up next week and then we can look to get the fix merged into master.
 
Cheers,
 
Dave
 
> On 26 Jun 2020, at 14:54, zhangtengfei@sjtu.edu.cn wrote:
>
> Hi Dave,
>
> Thank you very much, using the fix in your branch the code addresses the issue. I really appreciate it!
>
> Best regards,
>
> Tengfei
> 
> From: David Moxey
> Date: 2020-06-26 16:14
> To: zhangtengfei@sjtu.edu.cn
> CC: nektar-users
> Subject: Re: [Nektar-users] Formation of the global linear system
> Hi Tengfei,
> 
> Yes indeed repeated calls to HelmSolve with the same GlobalLinSysKey should result in a cached system to avoid the overhead of repeatedly constructing the global system.
> 
> I think the issue is that in GlobalMatrixKey, if you take a look at the operator< function, we are simply testing for the presence of variable coefficients to determine whether they are the same key, rather than testing their contents, which is why you are getting the same system each time. This is for efficiency purposes, since if we check the coefficients every time we call HelmSolve (e.g. by hashing them), that would add considerable overhead.
> 
> I've added a new branch here in which I attempt to fix this here: https://gitlab.nektar.info/nektar/nektar/-/merge_requests/1159/diffs
> 
> Do you want to see if that addresses the issue? Note that not all of the solvers will compile with this enabled.
> 
> Cheers,
> 
> Dave
> 
> > On 23 Jun 2020, at 09:30, zhangtengfei@sjtu.edu.cn wrote:
> >
> > CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe.
> >
> > This email from zhangtengfei@sjtu.edu.cn originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list to disable email stamping for this address.
> > 
> > Dear Nektar users,
> >
> > I am writing a new solver using Nektar++ and it requires solving two different set of global linear systems (GLS1 and GLS2). The two sets of systems are inter-related on the RHS, i.e. therefore iterations between the two gobal linear systems should be performed.  The HelmHoltz coefficient matrices for GLS1 is different from GLS2. To solve each linear system, I called the HelmSolve() function respectively for GLS1 and GLS2. Problem is, even though I pass in different spatially variable coefficient maps for GLS1 and GLS2, the formed coefficient matrices for GLS1 and GLS2 seem to be the same. Only the first global linear system is formed correctly, and the second global linear system is recognized to be same as the first one.
> >
> > I found in the HelmSolve() subroutine there is a code snippet
> > GlobalLinSysSharedPtr LinSys = GetGlobalLinSys(key);
> > which scans the m_globalLinSysManager to retrieve the GlobalLinSysSharedPtr that has been formed with key. It seems that the code can only allow the existance of one single holmholtz global linear system, right? If so, does anyone know a way of solving this problem (or is there a solver in the code that I can refer to)?
> >
> > Currently I have to use ClearGlobalLinSysManager() everytime I finish solving a global linear system, which cleans up the space and rebuild the new global linear system. But this is very time-consuming because the global linear systems are constructed again and again during the iteration between GLS1 and GLS2.
> >
> > Best regards,
> >
> > Tengfei Zhang
> > 
> > _______________________________________________
> > Nektar-users mailing list
> > Nektar-users@imperial.ac.uk
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.ic.ac.uk%2Fmailman%2Flistinfo%2Fnektar-users&amp;data=02%7C01%7CD.Moxey%40exeter.ac.uk%7C275b3c0831814ecf6e2608d818365913%7C912a5d77fb984eeeaf321334d8f04a53%7C0%7C0%7C637285969001972458&amp;sdata=mVPmgwKEnEy%2FLQyUAOhHhx6Ic%2BHmYBQh6KKdblnUUDw%3D&amp;reserved=0
> 
> --
> Dr David Moxey, PhD MMath MIMA FHEA
> Senior Lecturer in Engineering
> d.moxey@exeter.ac.uk | tel: 01392 724764 | web: davidmoxey.uk
> 
> Room 1.24, Hope Hall,
> University of Exeter,
> Exeter, EX4 4PL, UK.
> 
> _______________________________________________
> Nektar-users mailing list
> Nektar-users@imperial.ac.uk
> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
 
--
Dr David Moxey, PhD MMath MIMA FHEA
Senior Lecturer in Engineering
d.moxey@exeter.ac.uk | tel: 01392 724764 | web: davidmoxey.uk
 
Room 1.24, Hope Hall,
University of Exeter,
Exeter, EX4 4PL, UK.