cpuGaugeField constructor segfault

[jpfoley]

Trying to fix issue 76. Compiles fine now, but when I call the cpuGaugeField constructor using QUDA_REFERENCE_FIELD_CREATE + QUDA_QDP_GAUGE_ORDER, I get a seg fault. The same constructor with QUDA_REFERENCE_FIELD_CREATE + QUDA_MILC_GAUGE_ORDER works fine.
QUDA_ZERO_FIELD_CREATE + QUDA_QDP_GAUGE_ORDER is also okay.

[maddyscientist]

I guess the first question should be: what is your use case here? Are you creating a host field in QUDA_QDP_GAUGE_ORDER and passing the pointer to the cpuGaugeField? Since this use case is what all the dslash and solver tests use, I'm surprised that this one is seg faulting.

[jpfoley]

The seg fault arises in the constructor, which takes a reference to
GaugeFieldParam
as an argument. The pointer to the data is passed later using the
setGauge method,
but I have commented this out to make sure that the seg fault is in the
constructor.

On 08/21/2012 05:19 PM, mikeaclark wrote:

I guess the first question should be: what is your use case here? Are
you creating a host field in QUDA_QDP_GAUGE_ORDER and passing the
pointer to the cpuGaugeField? Since this use case is what all the
dslash and solver tests use, I'm surprised that this one is seg faulting.

—
Reply to this email directly or view it on GitHub
#78 (comment).

[jpfoley]

I should also say that GaugeFieldParam::gauge is set to NULL.

On 08/21/2012 05:19 PM, mikeaclark wrote:

I guess the first question should be: what is your use case here? Are
you creating a host field in QUDA_QDP_GAUGE_ORDER and passing the
pointer to the cpuGaugeField? Since this use case is what all the
dslash and solver tests use, I'm surprised that this one is seg faulting.

—
Reply to this email directly or view it on GitHub
#78 (comment).

[maddyscientist]

That is why then. Creating a cpuGaugeField with QUDA_REFERENCE_CREATE doesn't allocate any memory, instead it just points the gauge pointer at the one specified by the param. This is to wrap QUDA metadata around a gauge field that has already been created by another application.

What exactly are you trying to do here?

[jpfoley]

Understood. I am trying to modify unitarize_link_test.cpp to work with the latest version
of quda. Previously, I had used the computeFatLinkQuda function to generate a fattened gauge
field. This takes as input and returns ordinary host arrays. I had then passed a
pointer to the host array containing the fattened field to an instance of cpuGaugeField
and unitarized that. I had used milc gauge-field ordering in the past, and that seemed to work
(actually, the ordering was screwed up when I copied the data to the device, but it didn't affect my check).
The packGhost function now explicitly forbids milc field ordering, so I switched to QDP ordering, which
is when the segmentation fault appeared. I'll modify my code so the correct pointer is passed on instantiation, and add a check in the cpuGaugeField constructor.
I will probably also modify computeFatLinkQuda to take and return instances of cpuGaugeField instead of simple host arrays, which will also simplify the test code significantly.

Thanks.

[maddyscientist]

I see you've closed this, did you resolve the problem you were having?

The packGhost always has forbidden MILC ordering that I am aware of, but this is something that can fixed fairly easily. I recently extented support for BQCD ordering, so this is fairly recently in my brain, so I can do this if you need it.

[jpfoley]

Well, I figured that it's not really a bug. I'll push the changes I've
made today.
It's true that packGhost has never supported the MILC ordering, but the
check that excludes
the MILC ordering scheme explicitly was only added recently. In
unitarize_link_test.cpp, I had
used MILC ordering previously, and the code didn't complain and the test
passed, so there didn't seem to be a problem. However, this worked only
because I was checking the unitarization, and not trying to match the
fat links produced on the host and device. I.e., I just wanted to
generate a field of non-su(3) links to pass to the unitarization
function, and I did not care about the field ordering.
It would be useful to be able to use packGhost on MILC-ordered fields,
but it is not an urgent
priority.

On 08/22/2012 10:53 AM, mikeaclark wrote:

I see you've closed this, did you resolve the problem you were having?

The packGhost always has forbidden MILC ordering that I am aware of,
but this is something that can fixed fairly easily. I recently
extented support for BQCD ordering, so this is fairly recently in my
brain, so I can do this if you need it.

—
Reply to this email directly or view it on GitHub
#78 (comment).