Skip to content

Conversation

@susilehtola
Copy link
Collaborator

The Lebedev routine has an improperly namespaced copy routine. This PR puts that in the right namespace.

Alternatively, one could live with a single copy of this routine, but I don't understand the logic and layout of the code well enough to decide where it would go.

@wavefunction91 wavefunction91 added bug Something isn't working and removed bug Something isn't working labels Jul 2, 2023
using weight_container = typename base_type::weight_container;

if( npts == 6 )
detail::copy_grid<lebedev_laikov_6<RealType>>( points, weights );
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These need to be detail::lebedev::copy_grid to fix the compilation, but I see that you've also restored to maybe make this more general? I'm pretty pragmatic in these situations, if you have an idea on how we can reduce code bloat by sharing routines between this and the Beylkin Grids, I'm all for it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I fixed the compile.

And no, I don't have an idea how to reduce code bloat for this. Due to the templating, it looks like there will be instantiations of the copy_grid routine for each of the grids. Would it not suffice to use assignments?

Copy link
Owner

@wavefunction91 wavefunction91 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The more I think about this, the more I think what was previously there is fine. There's nothing lebedev specific about it - it simply stays that there are a set of static instances of grids (specified by a template parameter StaticGrid) with members points and weights and to copy those quantities into a passed set of containers. The function would be identical for the AH grids you've added in #9.

As for whether it should be std::copy or operator=, it's a matter of style, they're going to trigger identical behaviour - std::copy just allows the containers to be of different types.

If we want to make it less lebedev-y, we can move it to a separate file, but I see no reason to scope it to the detail::lebedev namespace (unless I'm missing something? Feel free to correct me if you still think there's a reason to scope it).


using point_container = std::vector< point_type >;
using weight_container = std::vector< weight_type >;
} // namespace IntegratorXX
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is in the wrong location and is what is causing the current compile errors for the unit tests. It needs to be at the end of the file to properly scope LebedevLaikov

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

^^ FWIW, I tested this locally and it works

@susilehtola
Copy link
Collaborator Author

Changes included in #9

@susilehtola susilehtola closed this Jul 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants