Release 1.0.0

[kinnala]

I'd like to proceed with 1.0.0 release even if the documentation is still lacking behind a bit, i.e. still advocating the use of some older features from which improved versions are available. We can then begin fixing those but I think there is no hurry.

Is there anything you'd like us to address before that @gdmcbain?

I think we could now consider adding DeprecationWarning to the old style forms. What do you think?

I have now successfully written numerical examples to one unpublished scientific article using the new style forms and are pretty happy with them.

Edit: Fixes #326 . Fixes #194 .

[kinnala]

We can also not deprecate the old style forms yet and simply first update all documentation before adding DeprecationWarning.

[gdmcbain]

I wonder what happened with Python 3.7 in Travis. Maybe something at the Travis end?

[kinnala]

It's probably some download step failing. I'll restart the build.

[gdmcbain]

Hmm, I typed a review here, I thought, but now I don't see it; unfamiliarity with working under Windows...

Meanwhile, I'm starting to look into adapting the examples to use the new-style forms, both to familiarize myself and to facilitate the step to 1.0.0.

[gdmcbain]

Yes. Following the exercise of rolling out the new-style forms in #362, I'm very happy with them. I think they're clearer and easier to use in almost all cases and worse in none.

The skfem.helpers module pretty well accomplishes my wished-for distinction between physical and numerical indices. I think it also looks sufficiently flexible to be able to expand to cope with future requirements, as hard as they are to foresee, of course.

[kinnala]

I added DeprecationWarning to this implicit casting procedure: 5a7a956 .

I wanted to simplify what gets passed to asm(..., w=w) as w. Previously it could be a bunch of different things which I found, at times, very confusing.

@gdmcbain Do you see any obvious downsides to this? It should be easy to fix the examples by writing w as {'w': w} or similar. The idea is basically to force the user to give a name to the field which also makes scenarios where multiple prescribed fields are needed more clear.

[gdmcbain]

Yes, I see. I wonder whether we can just use **kwargs somehow.

[kinnala]

I'm not sure how it'd go because we have to take two parameters for different Basis objects so that one can have different Basis for the solution and the test function (e.g. various Petrov-Galerkin methods).

[kinnala]

Unless Basis and DiscreteField were interchangeable somehow. Let me look into it cause it kind of makes sense.

[gdmcbain]

I'm not sure how it'd go because we have to take two parameters for different Basis objects so that one can have different Basis for the solution and the test function (e.g. various Petrov-Galerkin methods).

Hmm, yes, I see, or if projecting between bases, e.g. between overlapping meshes. I suppose it must happen that there can be coefficients (like thermal conductivity, whatever) on each side. I mean in the abstract a bilinear form might look like (something with test functions including operators and coefficients, something with trial functions including operators and coefficients) and the two bases in general (except in the strict Galerkin case) differ. How is that handled at the moment? I think I've only had to put coefficients on the side of the test functions, as in dot(grad(v), k * grad(u)) for thermal conduction with nonuniform thermal conductivity k.

[kinnala]

Now fixes #326 . I needed that in a research problem.

[kinnala]

Decided to remove the deprecation warning from Basis.get_dofs because it was heavily used and currently easy to support.

In future we should make a more thorough plan for handling DOF numbering and "named boundaries". Hopefully in 2.0.0.