Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Naming: "source" vs. "field" #27

Open
mgeier opened this issue Dec 11, 2016 · 4 comments
Open

Naming: "source" vs. "field" #27

mgeier opened this issue Dec 11, 2016 · 4 comments

Comments

@mgeier
Copy link
Member

mgeier commented Dec 11, 2016

Currently, we have the submodules sfs.mono.source and sfs.time.source.

This makes sense for now, but we could generalize it by calling it something with "field", because that's actually what the functions generate.

@hagenw
Copy link
Member

hagenw commented Mar 15, 2019

They can also generate a single point.

@mgeier
Copy link
Member Author

mgeier commented Mar 15, 2019

@hagenw That's a good point! In the future, time-domain sources may even be able to generate a time signal for a single point.

@fs446
Copy link
Member

fs446 commented Mar 15, 2019

These function create acoustical transfer functions either in frequency domain or time domain from the source location (exception plane wave) to one or many receiver locations, right? Typical terms used in acoustics are ATF and AIR, acoustical transfer function, acoustical impulse response. Some of these functions then are even Green's functions.

@mgeier
Copy link
Member Author

mgeier commented Mar 16, 2019

@fs446 Yes, but in the future, the time-domain functions might also be able to generate time signals for given locations in space. I don't know if that counts as AIR.

Either way, are you suggesting a different module name (or multiple modules)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants