Rob/mdanse trajectory filter

[RobBuchananCompPhys]

Description of work
TODO:

(Probably don't need to solve all of these immediately - some may become issues for further work after this is completed)

UI

• Odd crash occurs when returning to TrajectoryFilter job page from another job, error appears to be due to deleted grid layout components in the trajectory filter widget
• Trajectory filter widget panel inputs move around alot in layout - will change to a grid layout for all input components to improve stability
• Allow user to visualise the attenuated trajectory power spectrum alongside filter (currently non-enabled "Show attenuation" checkbox)
• When x-axis is set to energy units, the axis contracts - this should remain the same scale as for frequency units

UI &/or Backend

• Number of simulation frames post-filtering exceeds original frame count
• Investigate cause of atoms collapsing to 'ugly blob' when certain filter variants (seems to be highpass and bandpass removing low frequency vibrations) are applied to trajectory
• Ensure the Z- and S- domain representations of the transfer function polynomial are correct

Backend

• Filter class and filter-variant child classes
• Write metadata (filter configuration)

Tests

• Basic unit tests for correct functioning of filter class
• Full end-to-end test for a more complex molecular dynamics trajectory

Other

• Ensure sensible default values for filters
• Complete numpy docstrings for methods
• Apply black formatting

Fixes
A list of fixes.

To test
Please describe the tests that were run to verify the changes.

[oerc0122]

Suggested change

	settings_dict = dict()
	for setting, values in filter.default_settings.items():
	settings_dict.update({setting: values["value"]})
	return settings_dict
	return {setting: values["value"] for setting, values in filter.default_settings.items()}

Will do and be faster.

[oerc0122]

Any particular reason to use json.dumps (i.e. do you need False -> false, None -> null)?

Suggested change

	return (
	'{ "filter": "'
	+ f'{filter.__name__}"'
	+ ", "
	+ '"attributes": '
	+ f"{json.dumps(settings)}"
	+ "}"
	)
	return repr({"filter": filter.__name__, "attributes": settings})

If you need json.dumps

Suggested change

	return (
	'{ "filter": "'
	+ f'{filter.__name__}"'
	+ ", "
	+ '"attributes": '
	+ f"{json.dumps(settings)}"
	+ "}"
	)
	return json.dumps({"filter": filter.__name__, "attributes": settings})

Alternatively, if you want this f-string style, why not

Suggested change

	return (
	'{ "filter": "'
	+ f'{filter.__name__}"'
	+ ", "
	+ '"attributes": '
	+ f"{json.dumps(settings)}"
	+ "}"
	)
	return f'{{ "filter": "{filter.__name__}", "attributes": {json.dumps(settings)}}}'

[oerc0122]

Mixing class-level properties and methods will probably cause confusion in future.

[oerc0122]

Why do these need to be @propertys if they behave like standard attributes? Are they over-ridden on inheritance?

[oerc0122]

Dictionary keys already behave like sets, no need to cast. Also, are you looking for:

Suggested change

	{"filter", "attributes"} in set(dict_value.keys())
	{"filter", "attributes"} < dict_value.keys()

[oerc0122]

Considered bad practice to assign a lambda.

Always use a def statement instead of an assignment statement that binds a lambda expression directly to an identifier

-- PEP-8

[oerc0122]

Suggested change

	if on:
	self.bound_freq_widget.setEnabled(True)
	return
	self.bound_freq_widget.setEnabled(False)
	self.bound_freq_widget.setEnabled(on)

[oerc0122]

In fact this function could just be:

      toggle_bound_frequencies = self.bound_freq_widget.setEnabled

[oerc0122]

Suggested change

	self._figure_info.append(f" ")
	self._figure_info.append(f" ")
	self._figure_info.append(" ")
	self._figure_info.append(" ")

[oerc0122]

Suggested change

	if key in defaults.keys()
	if key in defaults

[oerc0122]

Not sure why this isn't a method on Filter