Somehow, I made the Matlab wrapper work on my Mac.

[boilingwu]

Hi Ben,

I was trying to install this wrapper on my mac. The python one works fine. But there are many small issues with the Matlab. I tried Matlab R2019a on my Mac Pro (Sierra) and R2020a on my MacBook Pro (Catalina), they both don't work. Somehow, I made it works. I am posting my experience here and hope it can help some other folks.

---

1. Mex commands with fortran doesn't work. "No supported compiler was found." The first step of the installation in matlab is mex 'DC3D0wrapper.F' mex 'DC3Dwrapper.F' When I run these commands I got errors: "No supported compiler was found.". This is because for the fortran compiler I previously used is gfortran. This error appears because mex in R2019a and R2020a don't support gfortran, and one needs to use "Intel® Parallel Studio XE Composer Edition for Fortran macOS" (requirement info on [https://www.mathworks.com/support/requirements/previous-releases.html]). People on web says there are some ways to go around by modifying xml file so one can still use gfortran. I didn't take that path. I think it's too much hacking for me. I register on Intel as a student and get the Intel Fortran Comiler. If you are using R2016b and above on Mac, you probably need to do the same thing.

After I install the Intel Fortran Compiler, I still need to fix some environment variable issues. I am using Intel Fortran Compiler 2018, so I need to assign the 'IFORT_COMPILER18' variable before doing mex by, setenv('IFORT_COMPILER18','/opt/intel/compilers_and_libraries_2018.6.243/mac/'); a detail explanation can be found in [https://www.mathworks.com/matlabcentral/answers/355720-mex-can-t-find-intel-parallel-studio-xe-for-fortran-2017]

The mex issues are fixed for my Mac Pro (R2019a) by this point. For my MacBook Pro (R2020a), somehow I also need to solve two other small bugs to make the mex works: a. I need to add to PATH the directory of the ifort binary to help the mex command find ifort, setenv('PATH', [getenv('PATH') ':/opt/intel/compilers_and_libraries_2020.2.258/mac/bin/intel64:/opt/intel/compilers_and_libraries_2020.2.258/mac/bin:/opt/intel//debugger_2020/gdb/intel64/bin:']); b. After that, I get an error xcrun: error: unable to find utility "clang", not a developer tool or in PATH I follow this thread to solve this issue, [https://www.mathworks.com/matlabcentral/answers/512901-mex-xcodebuild-error-sdk-macosx10-15-4-cannot-be-located]

---

2. Once I made the mex works, the DC3D0 function works just fine. But whenever I ran the DC3D function (rectangle source), both the R2019a and R2020a will give me a segmentation error and I need to quit and restart. I get into the DC3Dwrapper.F to debug and try to use mexPrintf(txt) to find out which line gives me the segmentation error. Amazingly, the segmentation error magically disappear when I put C Specify alert to be printed character (len=*), PARAMETER :: txt = "API says hello!"
   behind "C Check for proper number of arguments." (approximatly line 114), and put C Call the API call mexPrintf(txt) above "call DC3D(sngl(alpha)," (approximately at line 203)

I don't know why this can fixed the segamentation bug but it just did. I guess probably by calling the mxPrintf() some undefined pointer is overwritten. But I am not a CS expert so I really don;t know what happen. This is not a longterm solution because printing out a sentence really slow down the calculation. I hope someone later can find a better way to fix this bug.

In the end, I want to thank you for making this code. You make it very easy for people like me who don't know much about FORTRAN to use Okada 1992 solution. Very much appreciated!

Baoning

[tbenthompson]

Thanks! I'll leave this up and open in case it helps anyone.

[boilingwu]

An update for the point number 2 in my comment above. I have found a way to solve the segmentation error with a better solution.

The segmentation error seems to originate from the use of FORTRAN function "sngl" in the DC3DWrapper.F. Matlab mex wrapper seems unhappy with the conversion from double to single. My previous method of calling a "mexPrintf" function before calling DC3D magically works, but it would produce a lot of output, which I don't like. Anyway, it is not a good solution because I didn't solve the problem. But at that time I need to rush some results so I was happy with the "dirty" fix

Yesterday I came back to this wrapper. Trying to get a better solution. I tried many solutions that play around with the conversion within the .F file, but they didn't work. Eventually, I find an easy solution that works. Basically, I get rid of all the precision conversions within the .F file, making all the variable double. Then I go to the original Okada DC3D.f file to make all the real variables double. In fact, there are only two places needed to be changed, one at the beginning of the DC3D0 function and one at the beginning of the DC3D function. Maybe the DC3D0 function doesn't need to be changed, but I change it anyway.

And it works! About my setup, it is Catalina 10.15.7, Matlab R2020a, ifort version 19.1.2.258.

[tbenthompson]

Thanks for this! Would you be interested in submitting a pull request so that we can consider merging your changes into the repo? I've stopped using matlab so I won't be able to test your changes, but you might be one of the only matlab users of this package so if it works for you, it's probably good enough.

[boilingwu]

Thanks, Ben. Sure. I went to the Pull Request page but it doesn't allow me to create a new Pull Request. Maybe I missed some steps---I am not familiar with Github. Can you give me more instructions on how to create a new Pull Request? Or could I send you the change via email instead?

Baoning

[tbenthompson]

Totally fine if you want to send me the changes via email. But, if you do want to submit a PR using GitHub, that's a bit easier for me to work with. Here's a tutorial on how you would do that: https://jarv.is/notes/how-to-pull-request-fork-github/