Improve attrs usage in simulation package

[rafmudaf]

Fix and improve attrs usage in floris.simulation package

Starting in v3, FLORIS adopted the attrs library as the method for creating the data structures throughout the floris.simulation package. There are numerous benefits of using attrs including that slotted classes are more memory efficient. However, this adopted of attrs as the infrastructure for created classes was incomplete. Specifically, BaseModel and BaseClass were not attrs-derived, and so their subclasses were a mix of slotted and dict-based classes. In addition to missing out on potential memory efficiency, this allowed for monkey patching which resulted in an inconsistent architecture within a few class definitions.

This pull request ensures the usage of attrs-derived classes throughout the floris.simulation package primarily by adopting attrs in the BaseClass and BaseModel definitions. In order to maintain a fully attrs-derived inheritance tree while avoiding attrs creeping into floris.tools, the use of the logging class was changed from inheritance to composition within floris.simulation and its use remains unchanged in floris.tools - except the name changed from LoggerBase to LoggingManager to reflect that it isn't necessarily a base-class. If it were to remain only a base-class, then it would have to use attrs to enable slotted classes. Lastly, a few monkey patched attributes were added to their corresponding class declarations.

Related issue

This is tangentially related to #699. I came across this while testing that one.

Impacted areas of the software

The infrastructure to create the classes within floris.simulation.

Additional supporting information

Given significant upcoming changes to FLORIS (see the v4 project), this change allows us to have a better understanding of the architecture of the existing code so that we can more easily and accurately build upon it.

[rafmudaf]

@bayc One thing I noticed (via the failing examples) is that Farm.turbine_fCts_sorted is only created for the multidimensional Cp and Ct turbine feature. Is there any reason not to do this for all cases? We could make this part of the if-statement the default and the other is the special case.

[paulf81]

This sounds like a great catch and really useful improvement @rafmudaf , thank you!! Do you think we'll see a difference in memory usage after merging or is this more of a preventative measure against issues?

[rafmudaf]

There's no runtime issue that this fixes, but it does improve the readability of the code since you can now scan the attributes at the top of each class and be sure that those are all of the ones available. Before this change, anything can be tacked on to any object at any time.

As for the memory consumption, we don't have the infrastructure in place to measure this, so I think there will be an improvement but I don't have a method to prove it.

[rafmudaf]

I've added the missing attribute declarations (see #750 (comment) and #711), and I'll open a separate issue to document the current state of the Farm class architecture and how to make it consistent throughout.

[RHammond2]

I think this is pretty good overall, but there are a couple of things I made comments on, that may or may not need to be addressed.

I assume by using the attrs slotted class more explicitly, there might be a speedup, but I wouldn't assume it's anything noteworthy.

[RHammond2]

Looks like the all comments I made are adequately addressed, so I'm switching to approved.

[rafmudaf]

Thanks for the thorough review @RHammond2