search

jmcmellen / splat

SPLAT! is an RF Signal Propagation, Loss, And Terrain analysis tool for the spectrum between 20 MHz and 20 GHz. This is a copy of the code written by John Magliacane
http://www.qsl.net/kd2bd/splat.html
GNU General Public License v2.0
74 stars 37 forks source link

Merge forks #12

Open der-stefan opened 4 years ago

der-stefan commented 4 years ago

Hi all,

SPLAT! is a great tool for radio amateurs, engineers and researches. A big thank you to the authors!

However, the software is growing older - or in other words it doesn't keep up the time. Just naturally for every open source project, the code gets forked and improved by some means. Over the past decades, online SPLAT! web services came and went, manuals in various languages came and went, but the main SPLAT! stayed all the same like a rock on the beach. So it would make sense to merge some forks back into SPLAT. I would like to mention just the most remarkable forks:

Just to mention: Similar, but NOT open source is Radio Mobile by Roger Coudé with the same "problems". Supported OS: Win 95, 98, XP - all very outdated, still working fine, but unchanged for many, many years.

Back to SPLAT!: It would make sense to "reunion" the forks within good, old SPLAT!

Edit: added 3 more forks and better descriptions.

hoche commented 4 years ago

Based on a quick overview of the three variants you mentioned, I think my fork and Cloud-RF's could probably be merged. I've done more memory-handling and other cleanup and more documenting; Cloud-RF has more modularization and lots more propagation models. Both are still in the bizarre "mostly C but with some C++" coding style.

QDeltaSoft's is pretty neat; I hadn't seen it before but it looks like it's gone off in a different direction. The code looks pretty nice but it's firmly entwined with QT, which means that using it to drive a website (Cloud-RF's business model) would be difficult.

Another interesting fork is https://github.com/amusselm/Parallel-LRP, which uses OpenCL to hand off the ITWOM calculations to video cards. It's a good idea but the implementation needs some more work. I cleaned up the ITWOM code to pure C specifically to support OpenCL, but there're some other issues like figuring out exactly where the most efficient place to slice the calculations is and how much of the DEMs you need to send to the card and so on.

der-stefan commented 4 years ago

I completely agree with your remarks. You can immediately notice if a program was written by an electrical engineer or by computer scientists - EEs' programs work fine, implement a freaky theory correctly, but are NOT made for later maintenance. And for not losing much time, just well-known tools are being used (like coding in C - works fine since the beginning of time and without major changes even on microcontrollers).

And yes - I am also one of those guys and unable to engineer a software from scratch in a professional way. If you, @hoche, get up the nerve to re-write SPLASH in C++ with classes, with encapsuled functions, split up logically into several files and providing an interface for e.g. an Qt application - just do it and you can be sure of the appreciation by many many people all over the world. SPLASH is an institution...

Your thread parallelization speeds up SPLASH already. Further optimization is just nice to have, but not very urgent.

der-stefan commented 4 years ago

Ok, let's not just talk, but sort things out: I started to move the current files around and to clean up the structure. It can be found in the branch "cleanup" in my fork but is not functional yet! Would it make sense, if you (@hoche ) give me write access to your repository? I criticized the number or forks, but did $fork++ on my own...

watkipet commented 4 years ago

I'm happy to work toward merging as well. However, we might not want to merge all of my changes:

I agree that the QDeltaSoft project is really nifty, but it looks like he just pulled in the ITWOM and perhaps ITM source without the rest of Splat!. If we pulled those out as a separate library, projects like QDeltaSoft could use them and get updates "for free."

@der-stefan, and @hoche - Would you like to split the code into proper C++ classes? How about if I contribute a class diagram explaining how I split things up? @Cloud-RF - You've already done some work splitting things up based on images, inputs, outputs, and models. Great!

watkipet commented 4 years ago

@hoche - I Just read in your README.md that, "The next release may see a CMake build system." Would you like any help with this? Since I did this work on my own repo, I can probably replicate it in yours. I can make a fork, do my CMake additions, and then submit a pull request. @der-stefan - Did you wand CMake in your repo too? Is that something you can pull over from @hoche if I do the work there? Should I do the work in your repo instead?

der-stefan commented 4 years ago

@watkipet: Great that you agree on merging all stuff! The very best would be to work here on a branch in the official SPLAT! repository, if write permissions can be granted (not sure about Github settings).

My opinion on your questions and on a future SPLAT 2.0:

As I only have some days/weeks from now to contribute to the project (but nearly fulltime), I would like to start right away. (Some quite extensive propagation simulations for a specific geolocalization application will be part of my PhD thesis and I want to finish this part not too late.)

Edit: Typos, fighting with German autocorrection on smartphone.

watkipet commented 4 years ago

@der-stefan - I've tried contacting @jmcmellen (John McMellen) a couple times but never got a response. He may have moved on to other things. I did get a response from the original author, John Magliacane, in July of 2017. He said he would look at my work and get back to me, but I suspect he's busy as well. John Magliacane never had a GitHub repo--just downloadable source. John McMellen put John Magliacane's source up on GitHub without any modifications that I'm aware of. John Magliacane's repo has only been the canonical repo by virtue of being the first as far as I can tell. I think it would be wonderful if his repo could be the one to which we can send pull requests, but again, I'm not sure if he's still involved. If not, I don't mind sending pull requests to you or @hoche.

Regarding a version 2.0: I'm not sure it would be possible to refactor the code into classes and incorporate your's and @hoche's changes in a days/weeks timeframe. But it might be doable for me to add CMake to version 1.* and you and @hoche to merge your changes together. Best of luck on your PhD thesis. Please don't disappear afterwards :).

hoche commented 4 years ago

OK, I added some branches to my fork and invited both of you (@der-stefan and @watkipet) as collaborators.

hoche commented 4 years ago

@watkipet: The reason I never did CMake is because in its current form the dependencies are pretty trivial: compile a few files in the top-level directory and link 'em together along with some well-known libs. That Makefile didn't take very long to bang out, and then I sorta hacked together the Visual Studio project. If it's going to get modularized and turned into a library with various wrappers, I think CMake is a good way to go.

I can probably do a bunch of the refactoring in a couple of nights once I make some time for it, but untangling main()...ugh. Not looking forward to that.

butterisgod commented 1 year ago

Any word on the 2.0 version?

hoche commented 1 year ago

There's a 2.0-alpha branch in my fork that's probably worth looking at. watkipet did some major C++ refactoring, and it incorporates a bunch of my and der-stefan's bugfixes as well. We could probably make that 2.0-beta by now; it's been in alpha for a couple of years.

der-stefan commented 1 year ago

Probably a good idea to proceed the 2.0 release. It has been a while since I contributed to the 2.0-alpha branch. If I remember correctly, I still wanted to introduce major changes which break compatibility with legacy splat. That has to be well-thought before, so I did not advance.

butterisgod commented 1 year ago

It would be greatly appreciated if a newer version could be finalized. I know many of us downstream developers were awaiting a 2.0 release to fix some pain points. This project underpins many other others, and unfortunately there aren't many open source signal propagation tools available that have this level of capability.

watkipet commented 1 year ago

Hans,

Do you know if the downstream developers expect 2.0 to have the same command-line interface as previous versions? Are breaking changes OK?

-Peter

On Fri, Jun 16, 2023 at 08:49 Hans Arndt @.***> wrote:

It would be greatly appreciated if a newer version could be finalized. I know many of us downstream developers were awaiting a 2.0 release to fix some pain points. This project underpins many other others, and unfortunately there aren't many open source signal propagation tools available that have this level of capability.

— Reply to this email directly, view it on GitHub https://github.com/jmcmellen/splat/issues/12#issuecomment-1594898685, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHMYZM4PKIOBZMJYGEEGTDXLR573ANCNFSM4KWTU4JA . You are receiving this because you were mentioned.Message ID: @.***>

der-stefan commented 1 year ago

The current 2.0-alpha version already breaks backward compatibility. In my opinion this is for good, but requires some more thoughts in order to release a new interface which will be stable for long time to come. Having JSON inputs and outputs is one major aspect.

watkipet commented 1 year ago

Agreed. I think I’d like to work on a 1.x release that maintains backwards compatibility. This will free everyone else to innovate for a 2.0 release. I think it’ll also provide good data for regression tests. I don’t recall if there’s a ‘develop’ branch, but it seems like that should be what goes into 2.0.

On Sat, Jun 17, 2023 at 12:31 Stefan Erhardt @.***> wrote:

The current 2.0-alpha version already breaks backward compatibility. In my opinion this is for good, but requires some more thoughts in order to release a new interface which will be stable for long time to come. Having JSON inputs and outputs is one major aspect.

— Reply to this email directly, view it on GitHub https://github.com/jmcmellen/splat/issues/12#issuecomment-1595842317, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHMYZPYI57TD6SUFYIZ3ITXLYA2TANCNFSM4KWTU4JA . You are receiving this because you were mentioned.Message ID: @.***>

butterisgod commented 1 year ago

Hans, Do you know if the downstream developers expect 2.0 to have the same command-line interface as previous versions? Are breaking changes OK? … -Peter On Fri, Jun 16, 2023 at 08:49 Hans Arndt @.> wrote: It would be greatly appreciated if a newer version could be finalized. I know many of us downstream developers were awaiting a 2.0 release to fix some pain points. This project underpins many other others, and unfortunately there aren't many open source signal propagation tools available that have this level of capability. — Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHMYZM4PKIOBZMJYGEEGTDXLR573ANCNFSM4KWTU4JA . You are receiving this because you were mentioned.Message ID: @.>

Yes, I am using the command line interface as a means to query the program. I've been discussing refactoring, so changes to the command line interface can be accommodated. I do think that having a command line interface is quite important for the project so I hope that you consider keeping some form of it in future releases.

I've been thinking about opening up the project and adding some capability - specifically removing the .ppm format as the primary means of export and adding a new capability like geoJSON that can be handled by modern open source mapping software. Currently, converting the ppm file for analysis (and frankly any raster image) is error prone and complex. I've actually moved to the uberH3 mapping system which I find quite easy to use and has significant portability. Also, I think you've mitigated this already, but the formatting of the terrain files using the ":" as a separator caused me some headaches in Linux :)

Anyways, I certainly hope you and the rest of the community continue development on this excellent project - I'm sure John Magliacane would be proud. It really is a foundational piece of software.

hoche commented 1 year ago

Did we break backwards compatibility in 2.0? If so, that needs to be mentioned in the release notes. As far as I know, the only thing that should have broken was the naming of the SDF files (moving from ":" to "_" as a separator), but all the flags and functionality should be the same.