Undefined symbols when specifying component coupling for DG in 1D

[Weixiong Zheng]

Howdy!

I extended my code from 2D to 1D. It is a vector hyperbolic system. The spatial discretization is DG1. When in 2D, I specified which component coupled to which and then:
DoFTools::make_flux_sparsity_pattern (dof_handler, dsp, cell_coupling, face_coupling);

It was perfectly fine and saved tons of memories for me in 2D. But when I tried in 1D case, I got the following problem:

Undefined symbols for architecture x86_64:
  "void dealii::DoFTools::make_flux_sparsity_pattern<dealii::DoFHandler<1, 1>, dealii::DynamicSparsityPattern>(dealii::DoFHandler<1, 1> const&, dealii::DynamicSparsityPattern&, dealii::Table<2, dealii::DoFTools::Coupling> const&, dealii::Table<2, dealii::DoFTools::Coupling> const&)", referenced from:
      NFPN_1D<1>::setup_system() in nfpn1d.cc.o
ld: symbol(s) not found for architecture x86_64

If I just use
DoFTools::make_flux_sparsity_pattern (dof_handler, dsp);

It will be fine.

So I am curious what's going on there.

Thanks in advance!
Weixiong

[Weixiong Zheng]

Forgot to mention, this is how I tried specifying coupling:

Table<2,DoFTools::Coupling> cell_coupling (fe.n_components(),

            fe.n_components());

    Table<2,DoFTools::Coupling> face_coupling (fe.n_components(),

            fe.n_components());

    for (unsigned int c=0; c<=n_comp; ++c)

    {

        for (unsigned int d=0; d<=n_comp; ++d)

        {

            if (c==d || c==d+1 || c==d-1)

            {

                cell_coupling[c][d] = DoFTools::always;

                face_coupling[c][d] = DoFTools::always;

            }

            else

            {

                cell_coupling[c][d] = DoFTools::none;

                face_coupling[c][d] = DoFTools::none;

                

            }

        }

    }

It works for multi-D but not 1D for me.
在 2016年3月1日星期二 UTC-5下午2:24:59，Weixiong Zheng写道：

[David Wells]

Hi Weixiong,

This is most likely a problem with deal.II; thank you for bringing this up so we can fix it :) The culprit seems to be

https://github.com/dealii/dealii/blob/master/source/dofs/dof_tools_sparsity.inst.in#L186

where we do not, for reasons I cannot determine, actually create a version of this function in 1D (but we do in 2D and 3D).

The function you are using is defined as a template in a source file (dof_tools_sparsity.cc), but we only ever instantiate it for dimensions 2 and 3 (which is done in the file I linked to above).

I will try to fix this. I will post something here when I see whether or not it makes sense to use this function in 1D.

Thanks,
David Wells

[David Wells]

Update: Unfortunately, while this should be fixed (and I am a little surprised that I have not yet run into this problem in my own DG codes), since deal.II does not handle faces in 1D in quite the same way as it does in 2D and 3D it will require a bit of work. I have solved a similar problem to this in the past and I know how to do this, but it may take me a few days to get around to it.

[Weixiong Zheng]

在 2016年3月1日星期二 UTC-5下午9:27:15，David Wells写道：

It's gonna be real exciting if it's not too hard to code it out. That really helped me out when I got trouble in 2D.

Update: Unfortunately, while this should be fixed (and I am a little surprised that I have not yet run into this problem in my own DG codes), since deal.II does not handle faces in 1D in quite the same way as it does in 2D and 3D it will require a bit of work. I have solved a similar problem to this in the past and I know how to do this, but it may take me a few days to get around to it.

On Tuesday, March 1, 2016 at 8:38:23 PM UTC-5, David Wells wrote:

Hi Weixiong,

I am happy I finally made kinda a little contribution to deal.II after all these days she helps me work out so many problems.

This is most likely a problem with deal.II; thank you for bringing this up so we can fix it :) The culprit seems to be

https://github.com/dealii/dealii/blob/master/source/dofs/dof_tools_sparsity.inst.in#L186

where we do not, for reasons I cannot determine, actually create a version of this function in 1D (but we do in 2D and 3D).

The function you are using is defined as a template in a source file (dof_tools_sparsity.cc), but we only ever instantiate it for dimensions 2 and 3 (which is done in the file I linked to above).

I will try to fix this. I will post something here when I see whether or not it makes sense to use this function in 1D.

I am looking forward to it! 

Thanks,
David Wells

Thanks,

Weixiong 

[Wolfgang Bangerth]

On 03/01/2016 08:27 PM, David Wells wrote:
> Update: Unfortunately, while this should be fixed (and I am a little surprised
> that I have not yet run into this problem in my own DG codes), since deal.II
> does not handle faces in 1D in quite the same way as it does in 2D and 3D it
> will require a bit of work. I have solved a similar problem to this in the
> past and I know how to do this, but it may take me a few days to get around to it.

But shouldn't the general approach still work, namely couple every dof on one
cell with every dof of all neighbors? You don't need faces for that, just the
ability to query neighbors (which works, except that you may have to recurse
until you finally get to an active neighbor in 1d, because the
1-level-of-difference rule doesn't hold in 1d).

Best
W.

--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@math.tamu.edu
www: http://www.math.tamu.edu/~bangerth/

[David Wells]

Dr. Bangerth,

I don't have the error messages in front of me right now so my following description may be slightly wrong.

 The problem ultimately lies with the fact that a face in 1D resolves to something like TriaAccessor<0, 1, 1>, which does not have a user flag variable; make_flux_sparsity_pattern keeps track of its progress by setting user flags on faces. Additionally, the function only couples dofs with support on the shared face, not all dofs.

Nevertheless you are probably right and we should probably specialize this function in 1D since the refinement behavior is different; I will look at it some more this evening.

Thanks,

David Wells

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
--- You received this message because you are subscribed to a topic in the Google Groups "deal.II User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dealii/7C9fBrkkZrE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dealii+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Wolfgang Bangerth]

On 03/02/2016 09:23 AM, David Wells wrote:
> Dr. Bangerth,

Unnecessary formality -- you know me well enough :-)

> I don't have the error messages in front of me right now so my following
> description may be slightly wrong.
>
> The problem ultimately lies with the fact that a face in 1D resolves to
> something like TriaAccessor<0, 1, 1>, which does not have a user flag
> variable; make_flux_sparsity_pattern keeps track of its progress by setting
> user flags on faces. Additionally, the function only couples dofs with support
> on the shared face, not all dofs.

Interesting. Aren't there methods where it is enough if a shape function has a
nonzero *gradient* to couple to the neighbor?

> Nevertheless you are probably right and we should probably specialize this
> function in 1D since the refinement behavior is different; I will look at it
> some more this evening.

Yes, I think doing an explicit specialization for the 1d case would be
simplest, given that the 1d situation is so much simpler to deal with.

[Wolfgang Bangerth]

The fact that you get a linker error is of course a bug.

But I'm curious why you think it would save you memory. In 2d/3d, the flux
sparsity pattern couples *all* DoFs on a cell with *all* DoFs on each of the
face neighbors, but unlike the regular sparsity pattern, it can ignore vertex
(and in 3d edge) neighbors, and consequently the sparsity pattern may be
emptier. It is not a strict subset of the regular sparsity pattern, though.

In 1d, *every* neighbor of a cell is a face neighbor, so the flux sparsity
pattern is *always fuller*. So if your code works with the regular sparsity
pattern, then you won't save any memory by using it.

Best
W.

PS: In future cases, if you find something that looks like a bug (just like
here), the easiest way to deal with it is to open an issue at
https://github.com/dealii/dealii/issues
This way the issue is tracked and won't be forgotten. For the current case,
I've opened an issue for you:
https://github.com/dealii/dealii/issues/2290

[David Wells]

Hi Weixiong,

Either way, this function should now work in 1D. I would be very grateful if you would try out the developer version and see if you get the results you expect in 1D :)

Thanks,

David Wells

[Weixiong Zheng]

David,

Oh! Great! I am working on something else, but will definitely try next Monday or so!

Thanks,

Weixiong

在 2016年3月7日星期一 UTC-5上午10:18:22，David Wells写道：

[Weixiong Zheng]

David,

I am not sure if I've installed the right version as you mentioned. I git cloned the package so I suppose that was the developer version on the Readme page.

When specifying coupling, I got the following error:

Undefined symbols for architecture x86_64:
  "void dealii::DoFTools::make_flux_sparsity_pattern<dealii::DoFHandler<1, 1>, dealii::DynamicSparsityPattern>(dealii::DoFHandler<1, 1> const&, dealii::DynamicSparsityPattern&, dealii::Table<2, dealii::DoFTools::Coupling> const&, dealii::Table<2, dealii::DoFTools::Coupling> const&)", referenced from:

      NFPN_1D<1>::setup_system() in gauss_tbb.cc.o

ld: symbol(s) not found for architecture x86_64

Throwing away the couplings in the make_flux_sparsity_pattern, then everything works fine.

Any idea?

Thanks

Best,

Weixiong


在 2016年3月7日星期一 UTC-5上午10:18:22，David Wells写道：

Hi Weixiong,

Thanks,

David Wells

[Wolfgang Bangerth]

On 04/04/2016 10:54 PM, Weixiong Zheng wrote:
>
> I am not sure if I've installed the right version as you mentioned. I git
> cloned the package so I suppose that was the developer version on the Readme page.
>
> When specifying coupling, I got the following error:
>
> Undefined symbols for architecture x86_64:
> "void dealii::DoFTools::make_flux_sparsity_pattern<dealii::DoFHandler<1, 1>,
> dealii::DynamicSparsityPattern>(dealii::DoFHandler<1, 1> const&,
> dealii::DynamicSparsityPattern&, dealii::Table<2, dealii::DoFTools::Coupling>
> const&, dealii::Table<2, dealii::DoFTools::Coupling> const&)", referenced from:
> NFPN_1D<1>::setup_system() in gauss_tbb.cc.o
> ld: symbol(s) not found for architecture x86_64
>
> Throwing away the couplings in the make_flux_sparsity_pattern, then everything
> works fine.

I thought this should have been fixed recently, in
https://github.com/dealii/dealii/issues/2290

What is the exact version of deal.II you are using? You can find out by
putting something like this into your main() function:
std::cout << "deal.II version " << DEAL_II_VERSION_MAJOR
<< "." << DEAL_II_VERSION_MINOR << std::endl;

Best
W.

[Weixiong Zheng]

It says deal.II 8.5 as what I saw in the VERSION file, which says 8.5 pre

Weixiong

在 2016年4月5日星期二 UTC-4上午7:43:28，bangerth写道：

[Wolfgang Bangerth]

On 04/05/2016 08:47 AM, Weixiong Zheng wrote:
> It says deal.II 8.5 as what I saw in the VERSION file, which says 8.5 pre
>

It's possible that there is another bug. Can you try to come up with a
minimal program that just creates a DoFHandler, a sparsity pattern, and
then calls the function in question? The program doesn't have to do
anything useful, just demonstrate the bug.