Better default ctor for MGLevelObject

[RichardYCJ]

close #16978

[RichardYCJ]

Since no argument is equivalent to template <> of the previous ctor, the only usage of this function is for default construction.

[peterrum]

The general issue is that MGLevelObject assumes that there at least one level. See for example:

dealii/include/deal.II/base/mg_level_object.h

Lines 300 to 305 in 58cc5c8

	template <class Object>
	unsigned int
	MGLevelObject<Object>::max_level() const
	{
	return minlevel + objects.size() - 1;
	}

which will now return -1 with the result that other function that use that are not well defined anymore.

Having the possibility to have an empty MGLevelObject would be great (and I thought about that already in the past as I was confused that there is always at least one level), but we will need to go through each function to check if this does not introduce some unwanted side effects.

[RichardYCJ]

The general issue is that MGLevelObject assumes that there at least one level.

@peterrum Yeah you are right! And does this one level object have to be initialized? I mean does the objects[0] (which is a shared_ptr) must not be nullptr?

If not, I can call object.resize(1) inside the default ctor.

[peterrum]

If not, I can call object.resize(1) inside the default ctor.

I am not sure if it is a good idea to have a dummy entry in the vector just to make the rest of the code working. Generally, the issue is that we store inclusive ranges [min_level, max_level] and not exclusive ones [min_level, max_level + 1[. This is why we always write loops like:

dealii/include/deal.II/multigrid/mg_transfer_global_coarsening.templates.h

Line 3785 in 9fe9a5f

for (unsigned int l = min_level; l <= max_level; ++l)

Personally, I would probably go with the solution to keep the internal vector empty (as suggested in this PR) and add asserts to other functions that indicate that they don't make sense if there are no levels...

But let's wait for the opinion of someone else who knows the historical background of this class.

[bangerth]

For one, max_level() defined as

template <class Object> 
 unsigned int 
 MGLevelObject<Object>::max_level() const 
 { 
   return minlevel + objects.size() - 1; 
 } 

will no longer be able to return an unsigned int. I would think that is at least surprising.

What kind of object do you have that cannot have a default constructor? In order to use the MGLevelObject later, you will have to reinit it to a nonzero size. In that case, if the stored type does not have a default constructor, what does reinit() do?

[RichardYCJ]

What kind of object do you have that cannot have a default constructor? In order to use the MGLevelObject later, you will have to reinit it to a nonzero size. In that case, if the stored type does not have a default constructor, what does reinit() do?

@bangerth reinit actually have variadic template parameter that can pass parameter in. I need the default ctor to let some class (that holds resources) to be default constructable. It will be reinit after like during setup_system.

[RichardYCJ]

Hi @peterrum, seems not much attention to this :-(

Maybe I can try adding reinit and see if it can pass the tests?

My argument is that users who use default ctor will, in most cases, reinit it to the MG level after like setup_system. And for those who just want a one level default constructable T, they can use MGLevelObject<T>(0, 0).