[StephenNneji]

• Fixes a bug in processCustomFunction
• Modifies C++ custom function interface to use std::vector instead of pointers

[StephenNneji]

@Arwel the python version of this example does indexes the bulkOut with contrast number i.e bulkOut[contrast] but this is not the case in the C++ version. Is this intentional?

[Arwel]

Wrong Arwel I'm afraid, you're after @arwelHughes. Been far too long since I did any c++

[StephenNneji]

Apologies @Arwel my bad

[arwelHughes]

I was just looking at that - no it isn't! Bulk out should come in as an array of all the bulk_outs for the given contrasts - mainly for backwards comptaibility but also there are (rare) occasions where the SLD of the previous contrast may be useful to know. So, if bulk_out is coming in as an array it shuld be bulk_out[contrast] (or whatever) in C also... btw - I very much like this! ... // Make the layers // oxide... output.push_back(oxideThick); output.push_back(oxSLD); output.push_back(subRough); 🙂 A p.s. Can we remove the debug 'std::cout... ' also?

________________________________ From: StephenNneji ***@***.***> Sent: Friday, January 19, 2024 9:53 AM To: RascalSoftware/RAT ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [RascalSoftware/RAT] Modifies the CPP custom layer interface to use std::vector (PR #195) @StephenNneji commented on this pull request.

________________________________ In examples/customLayers/customBilayer.cpp<#195 (comment)>:

@@ -70,40 +70,40 @@ extern "C" {

// Manually deal with hydration for layers in // this example. - double oxSLD = (oxideHydration * *bulkOut) + ((1 - oxideHydration) * oxideSLD); - double headSLD = (headHydration * *bulkOut) + ((1 - headHydration) * SLDhead); - double tailSLD = (bilayerHydration * *bulkOut) + ((1 - bilayerHydration) * SLDtail); + double oxSLD = (oxideHydration * bulkOut[0]) + ((1 - oxideHydration) * oxideSLD); @Arwel<https://github.com/Arwel> the python version of this example does indexes the bulkOut with contrast number i.e bulkOut[contrast] but this is not the case in the C++ version. Is this intentional? — Reply to this email directly, view it on GitHub<#195 (review)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AGMNVXWMASHC7SHTC6RPIH3YPI7CLAVCNFSM6AAAAABCBVHI6WVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTQMZSGAZDQMRTGU>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[StephenNneji]

@arwelHughes On closer inspection, the bulkOut is not passed as an array in the C++ apparently backsort does the indexing in processCustomFunction

The reason the MATLAB version receives an array is because of these lines in callMatlabFunction

if coder.target('MATLAB')
    % For backwards compatability with Rascal1...
    bulkOuts = zeros(nContrasts,1);
    bulkOuts(contrast) = bulkOut;

Should we be passing contrastBulkIns and contrastBulkOuts into these function instead?

[arwelHughes]

@arwelHughes On closer inspection, the bulkOut is not passed as an array in the C++ apparently backsort does the indexing in processCustomFunction

The reason the MATLAB version receives an array is because of these lines in callMatlabFunction

if coder.target('MATLAB')
    % For backwards compatability with Rascal1...
    bulkOuts = zeros(nContrasts,1);
    bulkOuts(contrast) = bulkOut;

Should we be passing contrastBulkIns and contrastBulkOuts into these function instead?

Well, as the comment says, if we just pass the 'per contrast' value of bulkOut we will essentially break 'r1ToProjectClass' for custom models, which for user engagement might be a bad idea initially. It's logical to do so though. I think we should persist with backwards compatibility initially and for a while, but the pre-announce the change for a future release.

But, there is actually no reason to do that for C custom models (they aren't available for RasCAL1, so no BC issues...). However, making C custom models using Coder source code generation (which I'm going to encourage) would be affected, sooo ... we should discuss at the next meeting.
A