Checks for inconsistent device types

[jwallwork23]

Closes #269.

This PR adds checks that overloaded operators are only applied to tensors that have the same device type.

It's sufficient to add the checks in the assignment operator and the binary operators as the unary operators will go through the assignment anyway.

The PR also adds checks that tensors have been constructed before they are interrogated. Related fix in the autograd example - the output tensor Q wasn't set up so didn't have a device type yet.

Questions:

• Do we also need to check the device indices are consistent?
  • -> future PR
• And what about data types?
  • -> future PR
• Can we add pFUnit unit tests that check these errors are raised as expected?
  • ->Doesn't seem so (see below).

[jatkinson1000]

Hey @jwallwork23 I just rebased this off of current main and then modified an example to check that if we try and add two with different devices we get an error raised as expected.

I used the below:

real(wp), dimension(5), target :: a, b, combine_data
type(torch_tensor) :: tensor_a, tensor_b, combine_tensor

a = [0.0_wp, 1.0_wp, 2.0_wp, 3.0_wp, 4.0_wp]
b = [0.0_wp, 1.0_wp, 2.0_wp, 3.0_wp, 4.0_wp]

call torch_tensor_from_array(tensor_a, a, tensor_layout, torch_kCPU)
call torch_tensor_from_array(tensor_b, b, tensor_layout, torch_kMPS)

combine_tensor = tensor_a + tensor_b
call torch_tensor_print(combine_tensor)

When tensors a and b are on CPU this passes fine, but in the above state (b on MPS) we get:

 Error :: cannot add tensors with different device types
Note: The following floating-point exceptions are signalling: IEEE_OVERFLOW_FLAG
STOP 1

Since we looked together in-person I am happy to approve this now.

For posterity we also discussed that this error warning could be made friendlier (parent routine, line number etc) but this is not a simple task and not to be done here.

[jwallwork23]

* Can we add pFUnit unit tests that check these errors are raised as expected?

I don't think it currently supports this - as far as I can tell, it can only mark certain tests as expected to fail, not interrogate error messages.

[jwallwork23]

[Rebased on top of main, fixing various conflicts]

[jatkinson1000]

I think I hadn't re-approved this because of the issues I had seen when trying to print a tensor.
See where I was investigating on mix_devices_temp branch.

Did we get to be bottom of that? I know it was mentioned in the meeting this morning.

Looking at the simplenet that failed that I uploaded I wonder if it was to do with a lack of importing the overloaded =.
There are also a few things that have changed with the addition of #303 so I will try and re-check this at some point to be certain.

[jatkinson1000]

OK, got nerd sniped.

The segfault was resolved by ensuring use ftorch, only : assignment(=) was present.

So that is good news. The bad news I guess is that this can be a tricksy bug/error to spot/resolve as there isn't much to go on from the FTorch output.
Not sure there is an easy fix to this however, but definitely something to be aware and make overly clear to users of when writing the docs @jwallwork23 .

[jwallwork23]

The segfault was resolved by ensuring use ftorch, only : assignment(=) was present.

So that is good news. The bad news I guess is that this can be a tricksy bug/error to spot/resolve as there isn't much to go on from the FTorch output. Not sure there is an easy fix to this however, but definitely something to be aware and make overly clear to users of when writing the docs @jwallwork23 .

Ah yes! Good work tracking it down. Opened #305 to address this.