Function to write gauge fields to disk

[leonhostetler]

Adds a function writeGaugeQuda to lib/interface_quda.cpp. This function is similar to saveGaugeQuda but writes the gauge field to disk instead of just copying it to host.

The motivation for this is a desire to be able to write a gradient flowed gauge field (i.e. gaugeSmeared) to disk after using performWFlowQuda or performGFlowQuda, without going through the rigamarole of allocating space from MILC, copying the flowed field back to MILC, and then writing it to disk. This will also allow us to write the fat and long links to disk, which is something we've been working on as well.

[weinbe2]

Thanks for the PR, Leon, this looks good to me and is a good contribution. I had an idea to simplify this which should be a relatively quick copy+paste job.

You could create a null CPU field at the start of the function, and then within the switch statement you could call cpuField.copy(...); as appropriate for the gauge field/fat links/long links. The smeared links would of course need the intermediate copy to a non-extended field, but in that case all of the logic can stay local, and you can create a GaugeField as opposed to a pointer thereto.

I think this should all "just work", but let me know what you think.

[leonhostetler]

@weinbe2 I have revised and retested. Let me know what you think. I think it is indeed better now with the logic for each case easier to follow and more self-contained/local.

[weinbe2]

Thanks @leonhostetler , this is exactly what I was picturing. I left one comment on the code for a trivial change. Otherwise, I'll do a cursory due-diligence build (I expect no surprises) and give an approve once the change is in.

[weinbe2]

I believe this break; needs to be below the closing } on the following line, if anything as a "best practice". The case QUDA_SMEARED_LINKS: block will always hit the break; in this case so it should be legal, but it still feels a bit too weird to me.

[leonhostetler]

Yes, I see what you mean. I have made the change.

[weinbe2]

This looks great. Thanks @leonhostetler